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?
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 im 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
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?
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
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
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:
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:
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!
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:
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.
