Was ein Velocity-Diagramm tatsächlich zeigt
Ein Velocity-Diagramm stellt deine letzten abgeschlossene Arbeit Sprints dar. Für jeden Sprint zeigt es zwei Balken nebeneinander, die Atlassian in der folgenden Dokumentation genau definiert: Dokumentation zum Velocity-Diagramm:
- Zugesagte Arbeit (der graue Balken) — „die gesamte Schätzung aller Vorgänge im Sprint zu dessen Beginn“. Das ist der Umfang, den das Team zu Sprintbeginn zugesagt hat.
- Abgeschlossen (der grüne Balken) — „die gesamte abgeschlossene Schätzung am Sprintende“. Das ist die tatsächlich fertiggestellte Arbeit.
Velocity selbst ist der Durchschnitt dieser abgeschlossenen Werte: „Velocity wird als Durchschnitt der gesamten abgeschlossenen Schätzungen über die letzten Sprints berechnet.“ Die meisten Velocity-Diagramme zeigen diesen Durchschnitt als horizontale Linie über den Balken. So erkennst du auf einen Blick, in welchem Tempo das Team üblicherweise liefert.
Die Schätzung kann in Story Points (die mit Abstand häufigste Einheit), als Anzahl der Vorgänge oder in einem anderen Schätzfeld erfolgen, je nach Konfiguration deines Boards. Unabhängig von der Einheit vergleicht das Diagramm immer dasselbe: was du geplant und was du geliefert hast.
So liest du es: vier Muster
Lies ein Velocity-Diagramm nicht Sprint für Sprint — betrachte das Muster über die letzten Sprints. Vier Muster verraten dir fast alles.
1. Abgeschlossene Arbeit liegt dauerhaft knapp unter der Zusage
Das ist der gesunde Normalfall. Teams schaffen selten 100 % der aufgenommenen Arbeit. Eine kleine, gleichmäßige Lücke (etwa 85–95 % der zugesagten Arbeit abgeschlossen) bedeutet, dass deine Planung realistisch ist. Die Durchschnittslinie bleibt waagerecht, und die Balken liegen nahe daran. Du kannst verlässlich prognostizieren.
2. Abgeschlossene Arbeit liegt Sprint für Sprint deutlich unter der Zusage
Regelmäßig zu hohe Zusagen. Das Team plant dauerhaft mehr, als es abschließt. Die Lösung ist nicht „härter arbeiten“, sondern weniger zusagen, näher am bewährten Durchschnitt der abgeschlossenen Arbeit. Zu hohe Zusagen untergraben unbemerkt das Vertrauen der Stakeholder, weil jeder Sprint wie ein verfehltes Ziel aussieht.
3. Die Balken schwanken von Sprint zu Sprint stark
Hohe Schwankungen — 30 Punkte, dann 8, dann 22 — bedeuten normalerweise, dass etwas anderes als das Arbeitstempo des Teams die Zahl beeinflusst: uneinheitliche Schätzungen, Umfangsänderungen mitten im Sprint, Urlaub oder große unfertige Stories, die zwischen Sprints weitergetragen werden. Ein sprunghaftes Diagramm fordert dazu auf, deinen Prozess zu prüfen. Prognosen aus einem einzigen Durchschnitt werden dadurch unzuverlässig (nutze stattdessen einen Bereich — siehe unten).
4. Ein langsamer, stetiger Anstieg
Ein allmählicher Aufwärtstrend über viele Sprints ist eine sinnvolle Verbesserung: Das Team wächst zusammen, Schätzungen werden stabiler und Hindernisse beseitigt. Sei aber vorsichtig bei einem plötzlichen Sprung — häufiger stecken Neuschätzungen oder Änderungen bei der Zählung des Umfangs dahinter als ein echter Produktivitätsgewinn.
Das eine Verhältnis, das du ergänzen solltest: Teile für jeden Sprint die abgeschlossene durch die zugesagte Arbeit. Das ist dein Say/Do-Verhältnis (manchmal auch Zuverlässigkeit von Zusagen genannt). Ein Team mit durchschnittlich 60 % sagt zu viel zu; ein Team mit dauerhaft über 100 % setzt seine Zusage bewusst niedrig an. Etwa 80–100 % sind ein guter Bereich. Ausführlich behandeln wir das hier: Sprint-Vorhersagbarkeit und das Say/Do-Verhältnis.
Wo du das Velocity-Diagramm in Jira findest
In einem unternehmensverwalteten Projekt öffnest du dein Scrum-Board und dann Berichte → Velocity-Diagramm. In einem teamverwalteten Projekt ist das entsprechende Werkzeug der Velocity-Bericht. Er misst die Velocity in Story Points oder anhand der Anzahl von Vorgängen. Beide benötigen die Funktion „Sprints“ und mindestens einen abgeschlossenen Sprint.
Eine strukturelle Einschränkung solltest du von Anfang an kennen: Das native Velocity-Diagramm befindet sich in den Berichten eines einzelnen Boards. Jira bietet nativ kein Dashboard-Gadget für Velocity. Du kannst es deshalb nicht neben Gadgets zur Sprint-Gesundheit, zum Burndown und zu Filtern auf einem gemeinsamen Dashboard platzieren, sondern musst den Bericht jedes Boards einzeln öffnen. Diese Lücke schließen Teams häufig mit einer Marketplace-App; dazu mehr am Ende. Den nativen Bericht und die App-Option haben wir hier ausführlich verglichen: Velocity für teamverwaltete Projekte.
Velocity für die Sprint-Planung nutzen
Die eigentliche Aufgabe der Velocity sind Prognosen — sie beantwortet „Wie viel können wir realistisch in den nächsten Sprint aufnehmen?“ und „Wie viele Sprints wird dieses Epic ungefähr brauchen?“. So nutzt du sie systematisch.
Plane mit einem Bereich statt mit einer einzelnen Zahl
Nimm deine letzten drei bis sechs abgeschlossenen Sprints. Bilde daraus nicht nur einen Durchschnitt, den du als unumstößlich behandelst, sondern notiere den niedrigsten und höchsten Wert. Liegen die jüngsten abgeschlossenen Werte bei 18, 22, 25, 19 und 24, ist deine realistische Kapazität „ungefähr 18–25, plane mit etwa 21“. Ein Bereich berücksichtigt natürliche Schwankungen echter Teams und verhindert eine Scheingenauigkeit in der Planung.
Prognostiziere Epics als Bereich von Sprints
Wenn ein Epic auf 120 Punkte geschätzt ist und dein Velocity-Bereich bei 18–25 liegt, entspricht das ungefähr 5 bis 7 Sprints. „5–7 Sprints“ zu kommunizieren ist deutlich ehrlicher — und hilfreicher — als mit vorgetäuschter Sicherheit „6 Sprints“ zu nennen.
Ziehe bekannte Unterbrechungen ab
Velocity setzt einen ungefähr normalen Sprint voraus. Reduziere die Kapazität für Feiertage, Urlaub oder einen geplanten Support-Dienst. Senke die Velocity wegen eines einmaligen Ereignisses nicht dauerhaft; plane lediglich diesen konkreten Sprint mit weniger Arbeit.
Faustregel: Ein ganz neues Team hat noch keine Velocity. Führe zunächst zwei oder drei Sprints mit bewusst niedrigen Zusagen durch, bevor du das Diagramm als Planungsgrundlage nutzt. Sowohl die Scrum-Literatur als auch Atlassians eigener Leitfaden zur Velocity betonen, dass Velocity ein Werkzeug ist, das ein Team im Laufe der Zeit aufbaut, keine Zahl, die du am ersten Tag festlegst.
Vier Fehler, die Velocity irreführend machen
1. Velocity verschiedener Teams vergleichen
Das ist der wichtigste Fehler. Story Points sind relativ — jedes Team schätzt anhand seiner eigenen bisherigen Arbeit und nicht auf einer absoluten Skala. Eine 8 des einen Teams ist eine 3 des anderen. Die Velocity zweier Teams zu vergleichen oder Teams sogar danach zu bewerten, ist sinnlos und schädlich: Es verleitet Teams dazu, ihre Schätzungen aufzublähen. Velocity lässt sich immer nur mit den bisherigen Werten desselben Teams vergleichen.
2. Velocity als Ziel behandeln, das maximiert werden muss
Sobald Velocity zum Ziel wird, verliert sie ihren Nutzen als Messgröße (ein klassisches Beispiel für Goodharts Gesetz). Teams erreichen ein Velocity-Ziel durch aufgeblähte Schätzungen, nicht dadurch, dass sie mehr Wert liefern. Das Ziel ist eine stabile, nachhaltige Velocity, die verlässliche Prognosen unterstützt — keine ständig steigende Zahl.
3. Die Definition von „Done“ ignorieren
Der Abschlussbalken zählt nur Vorgänge, die das Board als fertig betrachtet — standardmäßig nur die letzte Spalte. Wenn dein Team zusätzliche Status wie Released, QA Passed oder Accepted verwendet, die tatsächlich fertige Arbeit bedeuten, aber nicht als abgeschlossen zugeordnet sind, wird deine Velocity in jedem Sprint unbemerkt zu niedrig ausgewiesen. Stimme deine Definition of Done und die Statuszuordnung deines Boards aufeinander ab.
4. Vergessen, dass Unteraufgaben ausgeschlossen sind
Atlassians natives Velocity-Diagramm berücksichtigt ausdrücklich keine Schätzungen von Unteraufgaben. Wenn dein Team oft auf Ebene der Unteraufgaben schätzt, weist das native Diagramm einen zu niedrigen Durchsatz aus. Du musst entweder auf Story-Ebene schätzen oder ein Werkzeug nutzen, das Unteraufgaben optional einbeziehen kann.
Velocity dort anzeigen, wo das Team tatsächlich hinschaut
Die häufigste praktische Beschwerde über Jira-Velocity betrifft nicht die Berechnung, sondern den Ort. Das Diagramm liegt versteckt in den Berichten eines Boards, während das Dashboard die gemeinsame Sicht des Teams auf den Sprint bietet. Stand-ups finden am Dashboard statt; Reviews finden am Dashboard statt; Velocity nicht.
Genau diese Lücke schließt Velocity Chart for Jira . Das auf Forge basierende Dashboard-Gadget zeigt dasselbe Diagramm aus zugesagter und abgeschlossener Arbeit samt Durchschnittslinie auf jedem Dashboard — und ergänzt Funktionen, die im nativen Bericht fehlen: eine konfigurierbare Definition of Done, ein auswählbares Schätzfeld, optional berücksichtigte Unteraufgaben, die Say/Do-Kennzahl zur Vorhersagbarkeit und den Vergleich mehrerer Boards in einem Gadget. Es funktioniert mit unternehmensverwalteten und teamverwalteten Scrum-Boards und greift nur lesend zu — deine Daten verlassen Atlassian nicht.
Häufig gestellte Fragen
Was zeigt ein Velocity-Diagramm in Jira?
Zwei Balken pro abgeschlossenem Sprint: die Zusage (die gesamte Schätzung zu Sprintbeginn) und die abgeschlossene Arbeit (die gesamte Schätzung der bis zum Sprintende erledigten Arbeit). Velocity ist der Durchschnitt der abgeschlossenen Werte über die letzten Sprints und wird normalerweise als Linie angezeigt.
Was ist eine gute Velocity in Jira?
Es gibt keine allgemeingültige Zahl — Velocity wird in den eigenen relativen Story Points eines Teams gemessen. Eine gute Velocity ist stabil und berechenbar (abgeschlossene Arbeit entspricht über die Zeit ungefähr der Zusage), nicht möglichst hoch. Vergleiche niemals die reine Velocity zweier verschiedener Teams.
Auf wie vielen Sprints sollte eine Velocity-Prognose basieren?
Die letzten drei bis sechs abgeschlossenen Sprints. Weniger als drei schwanken zu stark; ein deutlich längerer Rückblick kann ein anderes Team oder eine andere Arbeitsweise vermischen. Nutze den Bereich vom niedrigsten bis zum höchsten Wert, nicht nur den Durchschnitt.
Warum ist mein Velocity-Diagramm leer oder zeigt null?
Meistens gibt es einen von zwei Gründen: Das Board ist ein Kanban-Board (ohne Sprints keine Velocity), oder deine Vorgänge werden in einem anderen Feld geschätzt, als das Diagramm ausliest. Velocity benötigt ein Scrum-Board mit mindestens einem abgeschlossenen Sprint. Das Schätzfeld muss dem entsprechen, das dein Team tatsächlich nutzt.
Hat Jira ein Velocity-Dashboard-Gadget?
Nativ nicht — das Velocity-Diagramm befindet sich im Bereich „Berichte“ eines einzelnen Boards, ohne integriertes Dashboard-Gadget. Um Velocity auf einem Dashboard anzuzeigen, verwendest du eine Marketplace-App wie Velocity Chart for Jira.
Sieh deine Velocity auf jedem Dashboard
Velocity Chart for Jira zeigt zugesagte und abgeschlossene Arbeit, die Durchschnittslinie und Say/Do auf jedem Dashboard — mit deiner eigenen Definition of Done, auf unternehmensverwalteten und teamverwalteten Boards.
Im Marketplace ansehen →