Velocity basiert auf zwei Zahlen pro Sprint
Jede Velocity-Berechnung beruht auf zwei Summen, die Jira für jeden abgeschlossenen Sprint bildet. Atlassians Dokumentation zum Velocity-Diagramm definiert sie so:
- Zugesagte Arbeit — „die gesamte Schätzung aller Vorgänge im Sprint zu dessen Beginn“.
- Abgeschlossen — „die gesamte abgeschlossene Schätzung am Sprintende“.
Velocity ist dann „der Durchschnitt der gesamten abgeschlossenen Schätzungen über die letzten Sprints“. Velocity ist also im Grunde nur der gleitende Durchschnitt des grünen Balkens. Alles Weitere betrifft die Berechnung dieser beiden Summen — und genau dort stecken die Details.
Wie die zugesagte Arbeit gezählt wird
Die Zusage ist eine Momentaufnahme zu Sprintbeginn. Wenn du auf Sprint starten klickst, erfasst Jira die Schätzungen aller Vorgänge, die sich zu diesem Zeitpunkt im Sprint befinden, und addiert sie. Daraus folgen einige Regeln:
- Vorgänge, die vor Sprintbeginn hinzugefügt werden, zählen zur Zusage.
- Vorgänge, die nach Sprintbeginn hinzugefügt werden, zählen nicht zur Zusage — sie sind eine Umfangsänderung und keine ursprüngliche Zusage.
- Vorgänge ohne Schätzung tragen null zur Zusage bei (genau deshalb verzerrt ungeschätzte Arbeit das Bild unbemerkt).
Diese Momentaufnahme führt später oft zu Verwirrung: Wird ein Vorgang nach Sprintbeginn neu geschätzt, ändert das die Zusage dieses Sprints nicht mehr — die Momentaufnahme wurde bereits erstellt.
Wie die abgeschlossene Arbeit gezählt wird
Die abgeschlossene Arbeit wird am Sprintende gemessen: als Summe der Schätzungen aller Vorgänge, die fertig sind. „Fertig“ bedeutet hier, dass sich der Vorgang in einem Status befindet, der der letzten Spalte deines Boards (der Done-Spalte) zugeordnet ist. Zwei Folgen sind besonders wichtig:
- Arbeit, die mitten im Sprint hinzugefügt und abgeschlossen wird, zählt zur abgeschlossenen Arbeit, obwohl sie nie zur Zusage gezählt hat. Deshalb kann der grüne Balken gelegentlich höher sein als der graue.
- Arbeit, die „im Grunde fertig“ ist, aber in einem Status außerhalb der Done-Spalte liegt, zählt nicht zur abgeschlossenen Arbeit. Verwendest du einen Status wie Released oder Accepted außerhalb der Done-Spalte, bleibt diese Arbeit für die Velocity unsichtbar.
Die Falle bei der Done-Zuordnung: Das native Diagramm zählt nur, was in der Done-Spalte des Boards liegt. Viele Teams haben mehr als einen Status für fertige Arbeit. Ihr tatsächlich abgeschlossener Umfang ist deshalb höher, als das Diagramm zeigt. Die Spaltenzuordnung deines Boards an deine tatsächliche Definition of Done anzupassen, ist die wirkungsvollste Korrektur für eine Velocity, die zu niedrig erscheint.
Das Schätzfeld bestimmt die Einheit
Velocity wird nicht immer in Story Points gemessen. Das Diagramm verwendet die Schätzstatistik deines Boards. Üblicherweise ist das eine dieser Optionen:
- Story Points — der Standard auf den meisten Scrum-Boards.
- Anzahl der Vorgänge — jeder Vorgang zählt als 1; hilfreich für Teams, die nicht in Punkten schätzen.
- Ursprüngliche Zeitschätzung oder ein benutzerdefiniertes Zahlenfeld — abhängig von der Board-Konfiguration.
Der klassische Stolperstein: Ein Board ist für „Story Points“ konfiguriert, während das Team tatsächlich im Feld Story point estimate schätzt (oder umgekehrt). Das Diagramm liest dann ein leeres Feld, und die Balken liegen nahe null. Laut Atlassians Hinweisen zur Berechnung von Story Points summiert der Bericht das Feld, das für das Board festgelegt wurde — wenn die Balken falsch aussehen, prüfe deshalb zuerst dieses Feld.
Was fehlt: Unteraufgaben
Eine Regel überrascht fast alle: Schätzungen von Unteraufgaben werden nicht berücksichtigt im nativen Velocity-Diagramm. Es zählen nur Standard-Vorgangstypen. Wenn dein Team seine Schätzungen in Unteraufgaben statt in der übergeordneten Story einträgt, weist das native Diagramm systematisch eine zu niedrige Velocity aus. Du kannst entweder auf Story-Ebene schätzen oder ein Gadget nutzen, mit dem du Unteraufgaben ausdrücklich aufnehmen kannst.
Ein Rechenbeispiel
Betrachte einen Sprint. Zu Beginn enthält er vier Stories:
| Vorgang | Schätzung | Zu Sprintbeginn enthalten? | Am Ende fertig? |
|---|---|---|---|
| STORY-1 | 5 | Ja | Ja |
| STORY-2 | 8 | Ja | Ja |
| STORY-3 | 3 | Ja | Nein |
| STORY-4 | 5 | Ja | Nein |
| STORY-5 (mitten im Sprint aufgenommen) | 2 | Nein | Ja |
- Zugesagte Arbeit = 5 + 8 + 3 + 5 = 21 (die vier Vorgänge zu Sprintbeginn; STORY-5 ist ausgeschlossen).
- Abgeschlossen = 5 + 8 + 2 = 15 (alles, was am Ende fertig ist, einschließlich der mitten im Sprint aufgenommenen STORY-5).
Dieser Sprint zeigt also einen grauen Balken mit 21 Punkten und einen grünen mit 15 Punkten — ein Say/Do-Verhältnis von etwa 71 %. Beachte, wie die nachträglich aufgenommene STORY-5 die abgeschlossene Arbeit erhöht, ohne jemals die zugesagte Arbeit zu verändern: Diese Asymmetrie ist beabsichtigt.
Warum deine Berichte manchmal voneinander abweichen
Eine häufige Supportfrage lautet: „Warum stimmt mein Velocity-Diagramm nicht mit dem Sprint-Bericht (oder einer JQL-Summe der Story Points) überein?“ Die üblichen Ursachen:
- Neuschätzung nach Sprintbeginn. Die Zusage im Velocity-Diagramm bleibt auf dem Stand zu Sprintbeginn; eine aktuelle JQL-Summe berücksichtigt die heutigen Schätzungen. Wenn jemand einen Vorgang mitten im Sprint neu bewertet hat, unterscheiden sich die Zahlen.
- Status ohne Spaltenzuordnung. Ein Vorgang in einem Status, der keiner Board-Spalte zugeordnet ist, kann vollständig aus der Berechnung herausfallen.
- Umfangsänderungen. Während des Sprints hinzugefügte oder entfernte Vorgänge verändern die abgeschlossene Arbeit, aber nicht die Zusage.
- Unteraufgaben. Eine JQL-Summe, die Punkte von Unteraufgaben einschließt, stimmt nicht mit dem Diagramm überein, das sie ignoriert.
Das sind keine Fehler — sie ergeben sich direkt aus den oben beschriebenen Regeln zur Momentaufnahme und Statuszuordnung. Sie erklären aber, warum eine einzige „wahre“ Velocity schwieriger festzulegen ist, als es zunächst aussieht.
Velocity auf deine eigene Weise messen
Die nativen Regeln sind fest vorgegeben. Teams, deren Prozess davon abweicht — mehrere Done-Status, Schätzungen in Unteraufgaben, ein anderes Schätzfeld — erhalten deshalb eine Velocity, die ihre tatsächliche Arbeit nicht abbildet. Velocity Chart for Jira berechnet dasselbe Modell aus zugesagter und abgeschlossener Arbeit neu, erlaubt dir aber, die im nativen Bericht festgelegten Komponenten selbst zu bestimmen: Es rekonstruiert die Zusage anhand des tatsächlichen Sprintumfangs zu Beginn (aus dem Änderungsverlauf des Sprintfelds), lässt dich festlegen, welche Status genau als Done zählen, das Schätzfeld auswählen und Unteraufgaben optional einbeziehen. Anschließend wird alles auf einem Dashboard angezeigt, sowohl für unternehmensverwaltete als auch für teamverwaltete Boards. Die Berechnung bleibt gleich; du bestimmst lediglich die Eingaben.
Häufig gestellte Fragen
Wie wird die Sprint-Velocity in Jira berechnet?
Für jeden Sprint ist die Zusage die gesamte Schätzung der Arbeit zu Sprintbeginn; die abgeschlossene Arbeit ist die gesamte Schätzung der bis zum Sprintende erledigten Arbeit. Velocity ist der Durchschnitt der abgeschlossenen Werte über die letzten Sprints.
Zählt Arbeit, die mitten im Sprint hinzukommt, zur Zusage?
Nein. Die Zusage wird zu Sprintbeginn festgehalten. Später hinzugefügte Arbeit erhöht sie nicht, erhöht bei Abschluss aber den abgeschlossenen Wert — deshalb kann die abgeschlossene Arbeit manchmal größer sein als die zugesagte.
Sind Unteraufgaben im Velocity-Diagramm enthalten?
Nein — das native Velocity-Diagramm schließt Schätzungen von Unteraufgaben aus und zählt nur Standard-Vorgangstypen. Teams, die in Unteraufgaben schätzen, sehen eine zu niedrige Velocity, sofern sie kein Werkzeug verwenden, das diese optional einbezieht.
Warum stimmen mein Velocity-Diagramm und mein Sprint-Bericht nicht überein?
Meistens liegt es an Vorgängen, die nach Sprintbeginn neu geschätzt wurden (die Zusage ist eine Momentaufnahme zu Sprintbeginn), an Status ohne Spaltenzuordnung, Umfangsänderungen während des Sprints oder einer JQL-Summe, die vom Diagramm ignorierte Punkte von Unteraufgaben berücksichtigt.
Velocity so messen, wie dein Team arbeitet
Wähle deine Definition of Done, dein Schätzfeld und den Umgang mit Unteraufgaben — und sieh zugesagte und abgeschlossene Arbeit mit Velocity Chart for Jira auf jedem Dashboard.
Im Marketplace ansehen →