5 1 Vote
Artikel-Rating

Die Sprint Velocity ist eine zentrale Planungs- & Vorhersage-Metrik in Scrum. Sehr häufig gibt es hitzige Diskussionen darüber, wie die Velocity “richtig” verwendet wird. (Teilweise artet diese Diskussion sogar in echte Grabenkämpfe aus.) Deshalb möchte ich hier ein wenig näher auf die unterschiedlichen Varianten eingehen und Dir ihre Vor- und Nachteile bzw. Besonderheiten aufzeigen.

Denn ein richtig oder falsch gibt es zu dieser Frage eigentlich nicht. Es kommt hauptsächlich darauf an, was Du und Dein Scrum Team mit der Sprint Velocity transparent machen möchtet. Natürlich ist sie eine Metrik, mit der Vorhersagen gemacht werden sollen. Beispielsweise, ob das Sprintziel erreicht werden oder ob die Deadline eines Projektes gehalten werden kann (oder nicht).

Wirklich wichtig ist jedoch, ob ihr in Euren Sprints Nutzen für Eure Kunden schafft. Darüber sagt die Velocity in Scrum erst einmal recht wenig aus. Oder um es mit einem Agilen Prinzip auszudrücken:

Das wichtigste Fortschrittsmaß ist funktionierende Software.

Funktionsweise der Scrum Velocity

In der Vergangenheit haben sich Personentage als außerordentlich ungeeignet erwiesen, um Aufwände zu bestimmen oder vorherzusagen, wie lange es dauern wird, etwas umzusetzen. Deshalb sind eigentlich (fast) alle Scrum Teams dazu übergegangen, ihre Aufwände mit Hilfe von Story Points (SP) zu schätzen.

Für sich allein genommen sind diese jedoch erst einmal wenig aussagekräftig. Denn sie sagen ja nur aus, wie viel Aufwand etwas sein wird und nicht, wie lange es dauern wird.

Glücklicherweise arbeiten Scrum Teams jedoch in Iterationen bzw. Sprints, die immer gleich lang sind. Ein Scrum Team, das mit zweiwöchigen Sprints arbeitet, kann deshalb (rückblickend) die erledigten Story Points pro Sprint zusammenzählen und hat damit eine bessere Vorstellung davon, wie viel es im nächsten Sprint schaffen wird.

Die Sprint Velocity ist also nichts anderes als die Angabe SP/Sprint und funktioniert deshalb genauso, wie die Geschwindigkeitsangabe km/h.

Scrum Velocity als Durchschnittswert berechnen

Hier siehst Du die Velocity eines Scrum Teams, das in den letzten sieben Sprints 13, 20, 4, 8, 12, 15 und 10 SP erreicht hat. Die durchschnittliche Sprint Velocity dieses Teams liegt deshalb bei 11,7 SP/Sprint. Seine durchschnittliche Velocity beträgt also 12.

Diesen Durchschnittswert kann das Team nutzen, um beim nächsten Sprint Planning einzuschätzen, wie viel es im kommenden Sprint umsetzen kann.

Bereits an dieser Stelle wird die Scrum Metrik Velocity ein wenig willkürlich. Denn wie weit willst Du bei der Berechnung zurückschauen? 3 Sprints? 5? Oder sogar 20 Sprints?

Wenn Du beim gleichen Team nur auf die letzten 5 Sprints zurückschauen würdest, betrüge die Velocity des gleichen Teams lediglich 10.

Velocity Chart der letzten 7 Sprints

Du beeinflusst also schon durch die Auswahl der Sprintanzahl, welchen Durchschnittswert Du für die Velocity Deines Scrum Teams erhältst.

Meine persönliche Empfehlung ist im Übrigen ein Zeitraum zwischen 5 und 7 Sprints.

Scrum Velocity mit dem Median berechnen

Alternativ kannst Du zur Berechnung Eurer Scrum Team Velocity nicht den Durchschnittswert, sondern den Median verwenden.

Der Median ist der Wert, der von allen Messwerten “genau in der Mitte” steht. Wenn Dein Team also in den letzten sieben Sprints 10, 2, 8, 32, 15, 21,41 Story Points erreicht hat, ist der Median 15. (10, 2 und 8 sind die drei Sprints, die kleiner als 15 sind. 32, 21 und 41 sind die Sprints, die größer als 15 sind.)

Der Median hat den Vorteil, dass er im Gegensatz zum Durchschnitt weniger anfällig für Ausreißer ist.

Wenn die Velocity der letzten sieben Sprints beispielsweise 0, 0, 1, 15, 38, 45 und 72 wäre, läge der Median immer noch bei 15.

Velocity als Median

Die Sprint Velocity und unfertige User Stories

Ein Thema, das viele Scrum Teams immer wieder beschäftigt, ist der Umgang mit User Stories, die im Sprint nicht abgeschlossen wurden. Grundsätzlich habt Ihr hier zwei Optionen, die ich ein wenig ausführlicher besprechen möchte.
0
Wie geht Dein Team mit unfertigen User Stories und den dazugehörigen Story Points um?x

User Story neu schätzen & in den nächsten Sprint übernehmen

Bei dieser Variante wird die unfertige User Story (inklusive der dazugehörigen Aufgaben) in den nächsten Sprint übernommen und neu geschätzt, um keine Verzerrungen in der Velocity zu erzeugen. Wenn eine User Story mit 13 Story Points nicht fertig wurde und nur noch einige wenige Aufgaben übrig sind, kommt sie in den folgenden Sprint und wird von den Entwicklern des Scrum Teams neu geschätzt. (Etwa mit 2 Story Points.)

Der bereits erledigte Aufwand von 11 SP verschwindet damit aus der Velocity des Scrum Teams. Das kann man gut oder schlecht finden. Die Frage, die Ihr Euch in Eurem Team beantworten müsst, ist folgende:

Wollt Ihr mit der Velocity erledigten Aufwand sichtbar machen oder nur den Aufwand, der bis zur Review auch zu einem Ergebnis führte?

So gesehen kann ein Scrum Team eine sehr hohe Velocity haben und es jedoch trotzdem nie schaffen, zur Review auch nur eine einzige User Story abzuschließen.

Persönlich empfehle ich Dir die Neu-Schätzung unfertiger User Stories. Diskussionen über “verschwundene Aufwände” sind ein gutes Indiz dafür, dass ein Team “Punkte sammelt”.  Sinnvoller wäre es, sich auf ein auslieferbares Increment bis zur Sprint Review zu kümmern. Das erneute Schätzen von User Stories eliminiert alle Arbeit Deines Scrum Teams aus der Velocity, der zur Review kein Ergebnis brachte.

Das kann sogar ein Impuls für Dein Team sein, User Stories in Zukunft etwas kleiner zu schneiden, um nicht (mehr) so viele Punkte zu verlieren, falls eine User Story einmal nicht fertig werden sollte.

Die User Story verbleibt im alten Sprint

Eine andere Möglichkeit ist es, unfertige User Stories im vorherigen Sprint zu belassen und lediglich die dazugehörigen Aufgaben in den nächsten Sprint zu verschieben.

Sobald diese Aufgaben erledigt sind, wird auch die User Story geschlossen und die dazugehörigen SP auf die Velocity des vorherigen Sprints angerechnet.

Hier siehst Du ein Beispiel aus Azure DevOps, wie dieses Vorgehen auf dem Velocity Chart aussieht.

  • Im Sprint geplante und abgeschlossene User Stories werden dunkelgrün dargestellt.

  • Nach dem Sprint abgeschlossene User Stories bzw. Story Points werden hellgrün dargestellt.
  • Aktive User Stories werden dunkelblau dargestellt.

Scrum Velocity Chart - completed late

Am Velocity Chart dieses Scrum Teams kannst Du als Scrum Master leicht einige Themen ablesen, die Du mit Deinem Team spätestens in der Sprint Retrospektive besprechen solltest.

  • Kein einziger Sprint wurde sauber abgeschlossen. (Jedes Mal mussten Aufgaben in den nächsten Sprint übernommen werden.)

  • Aus dem ersten Sprint sind immer noch Aufgaben und User Stories offen.

  • Im dritten Sprint wurde bis zur Sprint Review überhaupt nichts fertig.

  • Es sind noch User Stories aus dem vorherigen Sprint offen.

  • Im aktuellen Sprint ist zwar viel aktiv, aber noch keine einzige User Story abgeschlossen.

Bugs, Improvements & andere Impediments

Ein zweites Thema, das viele Scrum Teams umtreibt, ist das Schätzen von Bugs und anderen Aufgaben, die keine User Story sind. Werden sie nicht mit Story Points versehen, sind sie in der Velocity “unsichtbar”. Betrachtest Du Bugs als Problem oder Impediment, das Euch daran hindert, Wert zu stiften, ist das auch vollkommen korrekt.

Die Behebung technischer Schulden sorgt dafür, dass Dein Scrum Team langsamer ist, was dann an der niedrigeren Sprint Velocity erkennbar ist.

Andererseits kann auch die Situation eintreten, dass ein Team in jedem Sprint sehr viele Bugs behebt, weil in der Vergangenheit sehr viele technische Schulden entstanden sind. In dem Fall führt das Nicht-Schätzen von Bugs dazu, dass Sprint Plannings zu einer reinen Lotterie werden. (Weil niemand einschätzen kann, wie viel Arbeit auf das Team wartet.)

Hinzu kommt außerdem, dass Bugs häufig einer Wundertüte gleichen und extrem schwer zu schätzen sind.

Velocity als Vorhersage-Metrik

Trotz all dieser Probleme ist die Velocity ein sehr hilfreiches Instrument für jeden Product Owner. Und zwar unabhängig davon, ob Du dabei mit einem Durchschnittswert oder dem Median arbeitest. (Oder ob Dein Team Bugs schätzt oder nicht.)

Mit Hilfe der Velocity kannst Du Vorhersagen darüber treffen, wann bestimmte Dinge fertig sein werden. Wenn sich beispielsweise im Product Backlog insgesamt 400 SP befinden und die historische Velocity des Teams bei 20 SP liegt, weißt Du, dass es wahrscheinlich 20 Sprints dauern wird, bis die im Backlog vorhandenen Themen fertig sind.

  • Wie Du als Product Owner mit Hilfe der Velocity Deines Scrum Teams Vorhersagen triffst, zeige ich Dir in meinem umfangreichen Artikel über das Burndown Chart.

Fazit zur Scrum Velocity

Ich hoffe, ich konnte Dir ein wenig dabei helfen, die Scrum-Metrik Velocity besser zu verstehen. Egal für welche Variante Du Dich gemeinsam mit Deinem Team entscheidest: Das Wichtigste ist, dass Ihr ein gemeinsames Verständnis darüber habt, was Eure Velocity ausdrückt bzw. ausdrücken soll. Im Grunde sind die von mir vorgestellten Aspekte letztlich auch eine Geschmacksfrage.

Falls Du noch Fragen zur Velocity hast oder Anregungen, Ideen oder auch Kritik zu diesem Artikel hast, schreib mir gerne einen Kommentar und auf der Seite!