Velocity – umgesetzte Funktionalität

​Eine Kennzahl für Teams kann die sogenannte Velocity sein. Das ist die umgesetzte Funktionalität im Sprint, die ein Team leistet. Wenn das Team eine kontinuierliche Verbesserung ​erzielt, dann wird auch die Velocity ​​im Laufe der Zeit größer. Doch es gibt natürlich Grenzen und Rahmen. Eine besondere Rolle bei dieser Fragestellung nimmt der Scrum Master ein. Er bereitet den Weg für eine gute Grundlage, damit das Entwicklungsteam arbeiten kann.

​Was ist die Velocity?

Velocity

​Die Velocity kennt jedes Scrum Team, denn es bezeichnet deren umgesetzte Funktionalität in einem Sprint. Dabei gilt, dass nur die Arbeit in die Velocity einfließt, die auch wirklich fertig geworden ist. Das machen Sie in Scrum über die sogenannte Definition of Done. Wenn das Team also Arbeit i​m Sprint Backlog abschließt, die der Definition of Done genügt, dann zählt diese Arbeit zur Velocity dazu.

​Die Velocity in der Praxis

​In diesem Abschnitt gehe ich auf typische Fragestellungen und Situationen in der Praxis ein. Dabei beschreibe ich typische Situationen, die ich kenne und die für mich relevant sind.

​Wie Sie die Velocity messen können

Velocity messen

​Die Velocity ist die Summe aller umgesetzer Funktionalität die im Sprint der Definition of Done entsprochen hat. Viele Teams arbeiten mit Story Points im Sprint, so ist es wenig verwunderlich, dass die Velocity auch in Story Points messen können. Natürlich ist das keine Pflicht, aber ich empfehle es häufig.

Zum Messen notieren Sie sich einfach, wieviele Story Points am Ende eines Sprint geschafft wurden. ​Sie prüfen ​dabei jedes Item gegen die Definition of Done. Ist es wirklich "fertig", addieren Sie einfach die Punkte zusammen. Ist ein Item nicht fertig, dann zählt es auch schlicht nicht zur Velocity dazu.

​Wer kümmert sich um die Velocity?

​Kümmern muss sich keiner um die Velocity im Sinne des Reportings. Häufig ist es der Product Owner, der einen Überblick über die mögliche Abarbeitung von seinen Product Backlog Items im Backlog benötigt und damit durch einfache Statistiken Szenarien durchspielen kann. Dabei schaut er sich die Velocity der einzelnen Sprints an und kann damit eine Prognose erstellen, was wahrscheinlich in einem Sprint geschafft werden kann.

​Bei einem meiner Team, die Scrum in der Hardware ​nutzen, hat das Entwicklungsteam diese Velocity immer selbst verfolgt, war sehhr stolz auf die eigene Leistung und hat sich das auch nicht nehmen lassen. Persönlich finde das prima und freut mich auch immer zu sehen, wenn so etwas passiert. Das Entwicklunsgteam übernimmt auch einmal im Tag das Reporting am Burndown Chart. Es liegt also nahe, dass dieses sich ebenso darum kümmert.

​Ist die Velocity unter Teams vergleichbar?

Velocity vergleichen

​Recht häufig werden Teams in meinen Augen durch das Management "verglichen". Der Versuch eines Vergleich liegt nahe, so gibt es doch klare Zahlen, die das Management in Relation setzen kann. So scheint eine ​Geschwindigkeit von 40 besser ist als eine von 20. Warum kann das andere Team nicht auch auf diese 40 kommen?

​Eine Velocity von einem "Team A" kann nicht mit einer anderen von "Team B" verglichen werden.  Die Velocity ist immer ein relatives Maß, dass sich überwiegend an einer relativen Größe orientiert, die durch eine Referenz bestimmt wurde. Nicht jedes Team hat die gleiche Referenz. Zudem können weitere Faktoren, wie

  • check
    ​die Rahmenbedingung des Prozesses
  • check
    ​das zu entwickelnde Produkte
  • check
    ​die Fähigkeiten des Teams selbst
  • check
    ​...

​eine Rolle spielen. Oft wird es trotzdem versucht, das zu tun. Meine Erfahrung ist hier, dass die Teams, wenn diese mal recht stabil sind und das über eine sehr lange Zeit, sich empirisch ein Faktor ableiten lässt, der zwischen Teams existiert. Die Frage, die Sie sich aber immer stellen sollten: warum brauchen und wollen Sie das? Was hilft es Ihnen und wo ist der konkrete Nutzen. Für das Management fragen Sie immer, "was können Sie, lieber Manager, für unser Team tun, damit wir eine höhere Velocity bekommen?".

​Velocity und technische Schulden

Velocity Vergleich

​Wenn Teams nur auf die ​Geschwindigkeit achten und bemüht sind diese zu erhöhen, dann wird ganz gerne nur auf Funtionalität geachtet. Das geht dann zu Lasten von technischen Schulden. Häufig sind die Teammitglieder dann im "Flow" und haben einen guten Lauf - da kann es schon mal passieren, dass die Metrik zum Ziel verkommt und nicht mehr als Hilfestellung gesehen wird.

​Teams ruhen sich auf einer Velocity aus

​Bei Teams kann man häufig einen Effekt beobachten, der releavnt für die Velocity und deren Verbesserung ist. Wenn das Team zu Beginn etwas schätzt und diese Schätzung auch erreicht, dann ist die Wahrscheinlichkeit recht hoch, dass das Team auch zukünftig diesen Wert erreichen will.

Es kann vorkommen, dass die Teams grundsätzlich nicht mehr versuchen sich zu verbessern, sondern mehr darauf den Fokus haben, diese Velocity zu erreichen. Das ist oft nicht verwunderlich, denn das Bedürfnis als "gute Entwicklung wahrgenommen zu werden" wird mit "wir treffen unsere Voraussagen" gleichgesetzt. Das reicht in vielen Organisationen schon aus, die früher wenig Transparenz über ihre Arbeit hatten. Scrum geht von einer kontinuierlichen Verbesserung aus und ruht sich nicht darauf aus.

Hier kommt der Scrum Master ins Spiel, denn der Scrum Master ist auch dafür verantwortlich, dass die Velocity des Teams steigt, nicht durch "einfach schneller arbeiten", sondern durch die Verbesserung der Rahmenbedingungen in der Praxis.

​Wem nützt die Velocity?

​Die Velocity nützt dem gesamten Scrum Team! ​Schauen wir uns dazu einmal typische Themen an, bei denen die Velocity eine Rolle spielen kann:

  • check
    ​Der Product Owner kann mit einer soliden und realistischen Velocity des Teams Releases planen und bekommt einen ungefähren Überblick darüber, die lange es dauert, bis bestimmte Product Backlog Items aus dem Product Backlog wahrscheinlich abgearbeitet sein könnten.
  • check
    ​Dem Entwicklungsteam hilft eine stabile Velocity natürlich auch, gerade wenn es um die eigenen Schätzungen geht. Viel Product Backlog Items können wir schaffen? Dabei kann - neben weiteren Faktoren - die Velocity helfen.
  • check
    ​Der Scrum Master kann prüfen, ob sich das Team langfristig verbessert und ob Maßnahmen zur Erhöhung der ​umgesetzen Funktionalität im Sprint greifen.

​Hinweise für die Praxis

​Experimente starten

​Wenn Sie sich als Scrum Master manchmal fragen, warum das Team nicht selbst einmal auf die Idee kommt, die Velocity zu erhöhen, also es einmal ausprobiert, noch ein Product Backlog Item mehr zu ziehen, dann schlagen Sie einmal ein Experiment vor!

Experimente sollten eine Hypothese haben und es ist am besten zu 50% nicht klar, ob das Experiment ein Erfolg wird. Dann können Sie nämlich am besten lernen! Nehmen wir an, das Team entscheidet sich ein Experiment hinsichtlich der Umsetzung von mehr Story Points zu machen. Es formuliert also ein kleines Experiment in dem es aufschreibt, dass es davon ausgeht, dass es ein Product Backlog Item in den Sprint zieht, es aber nicht schaffen wird. Natürlich setzt das Team trotzdem alles daran (Commitement, vgl. auch Scrum Werte), dass es alles menschenmögliche versucht, es zu schaffen.

Jetzt hat das Team die Chance zu lernen:

  • check
    ​Wenn das Team das Product Backlog Item tatsächlich nicht schafft, dann kann es den Grund extrahieren. Das könnte ja zum Beispiel sein, dass einfach die Zeit nicht ausgereicht hat. Das Team lernt aber, dass andere Faktoren im Team und der Infrastruktur soweit nicht Hindernis für das Experiment waren. Jetzt kann innerhalb der Retrospektive zum Beispiel das Experiment zum Anlass genommen werden, hier einmal etwas tiefer nach den Ursachen zu forschen.
  • check
    ​DIe Motivation des Teams wird nicht dadurch beeinflusst bzw. verringert, wenn das Product Backlog Item es nicht geschafft wird. Denn es war ein bewusstes Experiment, mit dem gelernt werden sollte. Das ist für mich immer ein wichtiger Punkt, damit die Motivation des Teams erhalten bleibt.

​Um es auch noch einmal zu wiederholen: das Lernen ist das Wichtigste überhaupt. Nichts ist schlimmer, als in starren Strukturen weiter zu trotten und nicht zu merken, dass Potentiale existieren, die nicht gehoben werden. Nutzen Sie dazu die Möglichkeiten der Retrospektive!

​Kennen Sie schon meine Tipps zu Scrum? Frisch und lecker in die Mailbox!

​Jederzeit abmeldbar, kein SPAM, versprochen! Siehe auch Datenschutzerklärung.

​Aufgaben nicht fertig, was und wann zählt dann?

​Natürlich stellt sich recht schnell die Frage, was das Entwicklungsteam eigentlich mit einem Product Backlog Item macht, dass es zwar im Sprint hat, aber nicht fertig bekommt. Zudem hat das Team schon eine Arbeit daran verrichtet. Wie wird also die Velocity bestimmt, wenn ein Product Backlog Item nicht fertig geworden ist? Dazu zwei Gedankenansätze:

  • check
    ​Das Team könnte die Story Points für das Product Backlog Item nicht zählen (ist auch nicht fertig, insofern logisch) und die Schätzung einfach nicht anpassen. Wird das Product Backlog Item in dem nächsten oder einem späteren Sprint wieder neu bearbeitet, dann würde - unabhängig der bereits erfolgten Arbeit - die volle, ursprüngliche Schätzung gezählt werden und damit in die Velocity einfließen. Das Team wird dann eine höhere Velocity aufweisen, als es tatsächlich geschafft hat.
  • check
    ​Das Team zählt die Story Points für das Backlog Item auch in diesem Fall nicht. Wird das Product Backlog Item später aber doch noch mal bearbeitet, wird es erneut geschätzt. Wurde bereits Arbeit geleistet, ist die Wahrscheinlichkeit recht hoch, dass die Schätzung geringer ausfällt. Es wird damit bereits geleistete Arbeit​ nicht gezählt. Die Velocity ist aber ein Stück weit in dem Sprint dann realistischer.

​Fragen Sie sich ...

​Was bringt es für Sie als Nutzen, wenn Sie eine oder die andere Variante für die Messung der ​umgesetzten Funktionalität nutzen? Diskutieren Sie diesen Aspekt auch einmal im Team und finden ein gemeinsames Verständnis darüber.

​Was trägt zur Verbesserung maßgeblich bei?

​Es gibt einige typische Dinge, mit der Sie die Velocity verbessern können. Ich möchte einfach ein paar Gedanken einwerfen und Sie prüfen dann gegen Ihre Realität.

  • check
    ​Ein stabiles Team ist in meinen Augen einer der Hauptpunkte, wie Sie die Velocity verbessern können. Dazu gehört auch, dass in einem Team alle die Personen sind, die auch benötigt werden, um ein Product Backlog Item fertig zu bekommen.
  • check
    ​Eine klare Definition of Done hilft dabei sich klar zu werden, wann Arbeit als wirklich fertig angesehen wird.
  • check
    ​Die Rahmenbedingungen für das Team werden regelmäßig überprüft und versucht zu verbessern. Hierbei wird überwiegend der Scrum Master aktiv und sucht aktiv solche Möglichkeiten.

Leave a Reply 0 comments

Leave a Reply:







>