Die Sprint-Velocity ist ein Geschwindigkeitsmesser für dein agiles Projekt und bietet einen beispiellosen Einblick in die Arbeitsleistung deiner agilen Teams und deiner Entwicklerteams. In diesem Leitfaden werden die Geheimnisse der Velocity in Scrum gelüftet. Du erfährst, wie man sie berechnet und wie du diese wichtige Metrik nutzen kannst, um die zukünftige Leistung deines Teams vorherzusagen.
Was ist Sprint-Velocity in Scrum?
In Scrum und anderen agilen Projektmanagement-Frameworks dient die Velocity (Geschwindigkeit) als agile Metrik für die Schätzung des Arbeitsaufwands, den ein Scrum-Team innerhalb eines bestimmten Zeitraums – typischerweise eines einzelnen Sprints – erledigen kann.
Du kannst die Velocity in Story Points ausdrücken, einer Maßeinheit zum Messen der Komplexität, des Risikos und der Unsicherheit von Aufgaben. Im Gegensatz zu zeitbasierten Metriken wie Stunden oder Tagen bieten Story Points eine nuanciertere Methode, die Arbeit zu schätzen.
Stell dir zum Beispiel eine User Story für die Entwicklung eines Anmeldebildschirms in einer Anwendung vor. Das Team könnte dieser Aufgabe einen Story-Point-Wert von 3 zuweisen, basierend auf der wahrgenommenen Komplexität und dem Aufwand, sie zu erledigen. Die Integration eines komplexen Zahlungs-Gateways könnte aufgrund der höheren Komplexität und potenzieller Risiken den Wert 8 erhalten.
Viele Faktoren beeinflussen die Anzahl der Story Points, die ein Teammitglied während eines zweiwöchigen Sprints abschließen kann, wie zum Beispiel die jeweilige Erfahrung, die Komplexität der Aufgaben und die Arbeitsdynamik des Teams. Neue Scrum-Teams haben in der Regel durchschnittlich 5–10 Story Points pro Person für einen zweiwöchigen Sprint.
Die Velocity des Teams zu kennen, kann bei der kontinuierlichen Verbesserung helfen. So können Teams zukünftige Sprints vorhersagen, Projekte planen und realistische Ziele setzen. Diese Metrik hilft Teams dabei, einen stabilen Arbeitsrhythmus zu entwickeln, Projektzeitpläne vorherzusagen und die Erwartungen der Stakeholder zu berücksichtigen. Sie ist darüber hinaus auch für eine effektive Sprintplanung und eine klare Erwartungshaltung der Stakeholder von großer Bedeutung.
Wie berechnet man die Sprint-Velocity in Scrum?
Normalerweise berechnest du die Sprint-Velocity am Ende jedes Sprints, indem du die Story Points oder andere Maßeinheiten für alle vollständig abgeschlossenen User Storys summierst.
Hier ist der Schritt-für-Schritt-Prozess zur Berechnung der Geschwindigkeit in Scrum:
1. Plane einen Sprint
Bevor ein Sprint beginnt, skizzierst du alle User Storys im Produkt-Backlog und weist ihnen Punkte zu. Zum Beispiel:
- Benutzerauthentifizierung zuweisen: 5 Punkte
- Payment-Gateway-Integration hinzufügen: 8 Punkte
- Suchfunktion implementieren: 3 Punkte
- Eine Benutzerprofilseite erstellen: 13 Punkte
- E-Mail-Benachrichtigungen implementieren: 2 Punkte
- Datenbankabfragen optimieren: 21 Punkte
- Ein Admin-Dashboard erstellen: 5 Punkte
Das Team sollte besprechen, wie es im kommenden Sprint die User Storys fertigzustellen gedenkt und dabei die Durchschnittsgeschwindigkeit früherer Sprints und andere Faktoren wie Feiertage oder externe Abhängigkeiten einbeziehen. Wenn die Durchschnittsgeschwindigkeit beispielsweise ohne Feiertage oder externe Abhängigkeiten 15 Punkte beträgt, könnte sich das Team für den nächsten Sprint auf User Storys mit insgesamt etwa 15 Punkten festlegen.
2. Abgeschlossene User Storys auflisten
Erstelle am Ende jedes Sprints eine Liste aller vollständig erledigten User Storys. Das sollten Storys sein, die ihre Akzeptanzkriterien erfüllt haben und die der Scrum Master und der Produktinhaber genehmigt haben.
Wenn eine User Story zu 90 % fertig ist, ist sie noch nicht vollständig abgeschlossen. Das Team sollte sie auf den nächsten Sprint verschieben und die Punkte anhand der verbleibenden Aufgaben neu bewerten.
3.Story Points überprüfen
Das Team sollte jeder abgeschlossenen User Story bereits Story Points zugewiesen haben. Falls Story Points neu gewichtet werden müssen, ist dies der richtige Zeitpunkt dafür.
Nehmen wir zum Beispiel an, das Team hat im aktuellen Sprint drei User Storys fertiggestellt – "Benutzerauthentifizierung zuweisen", "Payment-Gateway-Integration hinzufügen" und "Suchfunktion implementieren". Du könntest diesen Aufgaben die folgenden Story Points zuweisen:
- Benutzerauthentifizierung zuweisen: 5 Punkte
- Payment-Gateway-Integration hinzufügen: 8 Punkte
- Suchfunktion implementieren: 3 Punkte
4. Addiere die Punkte, um die Geschwindigkeit zu ermitteln
Als Nächstes musst du die Story Points für alle abgeschlossenen User Storys zusammenzählen. Die Summe der Story Points entspricht der Sprint-Velocity.
Im obigen Szenario wäre die Summe 5 Punkte + 8 Punkte + 3 Punkte = 16 Punkte. Dies wäre dann die Velocity für diesen Sprint.
5. Durchschnittliche Geschwindigkeit
Die Berechnung der durchschnittlichen Sprint-Velocity anhand der Anzahl der Sprints, die das Team abschließt, kann ein zuverlässigeres Maß für zukünftige Sprints sein. Das ist besonders nützlich für neu gegründete Teams oder solche, die sich in Größe oder Struktur geändert haben.
Wenn zum Beispiel die Velocity der letzten drei Sprints 14, 16 und 15 betrug, dann wäre die durchschnittliche Velocity (14 + 16 + 15)/3 = 15 Punkte.
Faktoren, die die Geschwindigkeit in Scrum beeinflussen können
Verschiedene Faktoren können die Scrum-Metriken und die Velocity beeinflussen. Wenn du das verstanden hast, kannst du die Leistung des Teams besser planen und kontinuierlich steigern.
Teamgröße und Fähigkeiten
Die Anzahl der Personen in einem Entwicklerteam und ihre jeweiligen Fähigkeiten können die Arbeit beeinflussen, die das Team während eines Sprints erledigen kann. Ein größeres Team kann in einem Sprint mehr Story Points abschließen. Allerdings können mehr Beteiligte den Kommunikations- und Koordinationsaufwand erhöhen.
Umgekehrt könnte ein kleines, hochqualifiziertes Team ein großes, weniger qualifiziertes Team übertreffen, indem es komplexe Aufgaben effizienter bewältigt.
Stabilität und Erfahrung im Team
Wenn Mitglieder des Scrum-Teams an mehreren Sprints zusammenarbeiten, werden sie wahrscheinlich viele der Macken ausbügeln können, die neue Teams behindern. Sie sind besser eingespielt und wissen, wer welche Aufgaben besonders gut erledigen kann.
Diese Teams haben gemeinsam viel Erfahrung gesammelt, was ihnen zugutekommt, wenn Probleme auftreten. Diese Vertrautheit kann die Geschwindigkeit erheblich erhöhen.
Komplexität von User Storys
Ein Sprint voller komplexer Storys resultiert normalerweise in einer niedrigen Velocity. Der Velocity-Wert kann irreführend sein, wenn die Komplexität der zugewiesenen Story Points nicht korrekt abgebildet ist.
Um eine konstante Geschwindigkeit aufrechtzuerhalten, streben einige Teams deshalb ein Gleichgewicht zwischen "Quick Wins" und komplexeren Tasks innerhalb eines Sprints an.
Externe Abhängigkeiten und Einschränkungen
Wenn dein Team auf ein anderes Team angewiesen ist, um Datenbank-Updates oder API-Integrationen durchzuführen, und dieses Team spät dran ist, kann das die Geschwindigkeit deines Teams direkt verringern. Sich dieser Abhängigkeiten bewusst zu sein und sie durch eine effektive Kommunikation zwischen den Teams unter Kontrolle zu halten, kann negative Auswirkungen auf die Geschwindigkeit abmildern.
Auch Feiertage oder wichtige Firmenveranstaltungen müssen in die Sprintplanung einbezogen werden, da sie die verfügbare Arbeitszeit reduzieren.
Velocity in Scrum verwenden
Das Wissen um die Sprint-Velocity deines Teams ist ein leistungsstarkes Tool für verschiedene Aspekte der Sprintplanung und des Projektmanagements, darunter:
Schätzung zukünftiger Sprints
Wenn du die durchschnittliche Velocity deines Teams kennst, gehören Ungewissheiten der Vergangenheit an und du kannst die Sprint-Velocity genau messen. Wenn dein Team in den letzten drei Sprints eine durchschnittliche Velocity von 50 Story Points erreicht hat, hast du eine datengestützte Baseline für die Planung des nächsten Sprints. Wenn dein nächstes Sprint-Backlog ungefähr 50 Story Points hat, kannst du davon ausgehen, dass dies ein realistisches Unterfangen ist.
Projektzeitpläne prognostizieren
Stakeholder verlassen sich eher auf datengestützte Schätzungen als auf Vermutungen oder Wunschdenken. Wenn dein Projekt-Backlog 200 Story Points hat und die durchschnittliche Geschwindigkeit des Teams 50 Story Points pro Sprint beträgt, kannst du getrost voraussagen, dass das Team wahrscheinlich etwa vier weitere Sprints benötigen wird, um das Projekt abzuschließen.
Über- und Unterengagement erkennen
Wenn die Geschwindigkeit eines Teams plötzlich auf 30 Story Points abfällt oder auf 70 steigt, ist das ein Alarmsignal. Ein stetiger Rückgang könnte bedeuten, dass sich das Team überfordert fühlt, und ein Anstieg könnte bedeuten, dass Teammitglieder unterfordert sind. Wenn du das beachtest, kannst du Anpassungen in Echtzeit vorzunehmen, wie zum Beispiel Tasks neu zuweisen oder Sprintziele überdenken.
Verbesserungen und iterativen Fortschritte kontrollieren
Wenn du die Geschwindigkeit über die Zeit verfolgst, kannst du herausfinden, ob dein Team effizienter wird oder ob bestimmte Probleme deine Aufmerksamkeit erfordern. Wenn deine Geschwindigkeit über mehrere Sprints von 40 auf 60 steigt, ist das ein Zeichen dafür, dass deine Prozessverbesserungen zu Ergebnissen führen.
Sprint-Velocity in Jira verfolgen
Neben weiteren agilen Berichten bietet Jira ein Velocity-Diagramm, damit dein Softwareteam die Velocity verfolgen, die künftige Leistung vorhersagen und die Sprintplanung vereinfachen kann. Dieses zentrale Tool zur Visualisierung des Arbeitsumfangs deines Teams hilft dir dabei, zukünftige Sprintziele genauer zu planen.
Jira bietet dir außerdem agile Metriken, kontextbasierte Einblicke und Funktionen für die Berichterstellung und das Projektmanagement, die dein Team benötigt, um seine Planung und Leistung zu optimieren.
Häufig gestellte Fragen: Sprint-Velocity in Scrum
Ist die Sprint-Velocity in Scrum dasselbe wie die Produktivität?
Nein, die Geschwindigkeit in Scrum ist nicht dasselbe wie die Produktivität. Die Geschwindigkeit ist in erster Linie eine Kennzahl zur Planung und Abschätzung, wie viel Arbeit ein Team in zukünftigen Sprints bewältigen kann.
Die Produktivität ist normalerweise eine umfassendere Kenngröße, die Faktoren wie die Qualität der Arbeit, die Effizienz der Prozesse und den Nutzen für das Unternehmen beinhalten kann.
Wie kann ein Team seine Sprint-Velocity verbessern?
Teams können ihre Velocity verbessern, indem sie regelmäßige Retrospektiv-Treffen abhalten, um zu besprechen, was gut gelaufen ist und was nicht, und Verbesserungen für den nächsten Sprint planen. Die Minimierung von Kontextwechseln – die Reduzierung häufiger Wechsel zwischen verschiedenen Aufgaben oder Projekten – kann zu einer höheren und konsistenteren Velocity führen.
Welche Einschränkungen gibt es bei der Verwendung von Sprint-Velocity in Scrum?
Velocity ist zwar ein wertvolles Planungstool, hat aber Einschränkungen und sollte nicht die alleinige Leistungsmetrik für die Bewertung eines Teams sein. Für einen umfassenderen Überblick über die Teamleistung solltest du erwägen, andere agile Metriken zu verfolgen.
Eine wichtige Einschränkung ist, dass Velocity nicht die Qualität der Arbeit oder den erbrachten Geschäftswert misst. Es ist ein quantitatives Maß, das die qualitativen Aspekte der Komplexität einzelner User Storys nicht berücksichtigt.
Velocity ist teamspezifisch – sie ist kein Maßstab für den Vergleich der Leistung verschiedener Teams. Jede Gruppe innerhalb eines Teams kann unterschiedlich arbeiten, was zu unterschiedlichen Velocitys führt. Eine geringere Gesamt-Velocity bedeutet nicht automatisch, dass ein Team weniger erfolgreich ist als ein anderes.
