Was ist Velocity in Scrum?

Velocity ist eine sehr einfache, aber dennoch leistungsstarke Methode, um genau zu messen, wie schnell ein Scrum-Entwicklungsteam im Laufe der Zeit geschäftlichen Wert liefert. Sie gibt Hinweise auf die durchschnittliche Menge der Product Backlog in ein Produkt-Increment während jeder Sprint durch ein Scrum-Team, wobei das Entwicklungsteam die Verfolgung nutzt. Daher berechnet man die AgileTeam-Performance, addiert einfach die Schätzungen von Features, Benutzerstories, Anforderungen oder Backlog-Elementen, die während einer Iteration erfolgreich geliefert wurden. Das Team sollte:

• Die Reichweite vorhersagen, die zu einem bestimmten Datum geliefert werden kann.
• Das Datum vorhersagen, an dem eine festgelegte Anzahl von Reichweiten geliefert wird.
• Unsere Einschränkungen verstehen, wenn wir festlegen, wie viel Reichweite wir in einem Sprint liefern werden.

Scrum-Performance-Beispiel

Bevor einige Iterationen abgeschlossen sind, gibt es einige einfache Richtlinien zur Schätzung der anfänglichen Performance eines Scrum-Teams, doch danach kann Ihr Team validierte historische Methoden zur Schätzung der Performance für Sprint-Planung. Auf Basis einer Reihe früherer Sprints stabilisieren sich die Performance-Schätzungen in der Regel und bilden eine zuverlässigere Grundlage für die Verbesserung der Genauigkeit der kurz- und langfristigen Planung für Scrum-Projekte.

Velocity misst die Menge an Arbeit, die ein Team in einer einzelnen Sprint-Iteration abschließen kann, und ist ein Schlüsselkennwert in Scrum. Sie wird berechnet, indem die Punkte aller vollständig abgeschlossenen Benutzerstories am Ende eines Sprints addiert werden. Punkte für teilweise abgeschlossene oder unvollständige Stories sollten nicht in die Berechnung einbezogen werden.

Schritt 1 – Berechnen Sie die Performance der ersten Iteration (Sprint)

Am Ende jeder Iteration addiert das Team die Aufwandschätzungen der Benutzerstories, die während dieser Iteration abgeschlossen wurden. Diese Summe wird als Performance bezeichnet.

Ein Agile-Team hat eine Iteration begonnen und plant, Story A und Story B abzuschließen, die mit 2 Punkten und Story C, die mit 3 Punkten geschätzt wurde. Am Ende der Iteration sind Story A und Story B zu 100 % abgeschlossen, Story C jedoch nur zu 80 %. Agile-Teams erkennen in der Regel nur zwei Abschlussstufen: 0 % oder 100 %. Daher zählt Story C nicht zur Performance, und die Performance für diese Iteration beträgt 4 Punkte.

Schritt 2 – Verwenden Sie die Performance, um die Anzahl der benötigten Iterationen zu schätzen

Nachdem die Performance aus Schritt 1 verstanden wurde, kann das Team die Schätzung dafür berechnen (oder überarbeiten), wie lange es dauern wird, das Projekt abzuschließen, basierend auf den Schätzungen der verbleibenden Benutzerstories, vorausgesetzt, die Performance in zukünftigen Iterationen bleibt ungefähr gleich. Dies ist in der Regel eine genaue Vorhersage, auch wenn sie selten exakt ist.

Angenommen, die verbleibenden Benutzerstories entsprechen insgesamt 40 Punkten; die Prognose des Teams für die verbleibende Arbeit beträgt 10 Iterationen.

Beziehung zwischen Performance und Story Points in Scrum

Story Pointswerden verwendet, um Größe und Komplexität zu messen – im Wesentlichen, wie lange es dauern wird, eine Aufgabe abzuschließen. Story Points sind eine relative Maßzahl für die Zeit, die benötigt wird, um eine Benutzerstory abzuschließen. Dieses Konzept stammt aus XP. Sie werden verwendet, um die Schwierigkeit einer Story zu bewerten, nicht, um einen Zeitrahmen festzulegen. Dadurch können Sie Story Points unabhängig von der Teamgröße oder der Art der Aufgabe verwenden.

Wie verknüpft man Geschwindigkeit mit Story Points?

1. Teams verwenden oft die „Geschwindigkeit“ als Produktivitätsmaßstab, um Außenstehenden genau anzugeben, wie schnell ein Scrum-Team ist.
2. Wenn die Schätzung der Story Points während des gesamten Projekts konstant bleibt, ist es sinnvoll, die Story Points zur Darstellung der „Geschwindigkeit“ zu verwenden.
3. Wenn Konsistenz nicht nur innerhalb einer Team, sondern auch zwischen Teams und sogar über die gesamte Firma hinweg gewährleistet ist, ermöglicht dies die Messung der Produktivität und den Vergleich der Teamleistungen.
4. Wenn die Werte der Story Points stabil bleiben, können sie als Referenz für die Release-Planung verwendet werden. Sie können später mögliche Zeitpläne bewerten.

Wie weist man Story Points einer Benutzerstory zu?

Ein Story Point ist eine relative Maßeinheit. Der erste Schritt, den Ihr Team unternehmen sollte, ist, eine Geschichte als Referenz zu definieren, damit sie andere Geschichten relativ zu dieser Referenz schätzen können. Laut Literatur sollte das Team die einfachste Geschichte im Backlog identifizieren und ihr 1 Story Point zuweisen, um diese Geschichte als Referenz für die Schätzung anderer Geschichten zu verwenden.

Es gibt zwei Arten von Skalen, die zur Erstellung von Story Point-Schätzungen verwendet werden:

• Lineare Skala (1, 2, 3, 4, 5, 6, 7, …)
• Fibonacci-Folge (0.5, 1, 2, 3, 5, 8, 13, …)

Es ist eine gute Idee, Ihre erste Benutzerstory zu schätzen, die Ihr Team kennt und weiß, wie lange sie dauert. Schätzen Sie dann Ihre nächste Benutzerstory. Wenn Ihr Team glaubt, dass sie weniger Zeit benötigt als die Referenzgeschichte, platzieren Sie sie links neben der Referenz. Schätzen Sie dann eine weitere Benutzerstory. Wenn das Team entscheidet, dass sie weniger Zeit benötigt als die Referenzgeschichte, aber mehr als die zweite Geschichte, platzieren Sie sie zwischen der Referenzgeschichte und der zweiten Geschichte. In diesem Beispiel verwenden wir die Fibonacci-Folge zur Schätzung von Geschichten:

Benutzerstory Story Points

Wie kann die Geschwindigkeit genauer geschätzt werden?

In Scrum hilft die Geschwindigkeit Ihnen zu verstehen, wie lange ein Team braucht, um das Produkt-Backlog abzuschließen. Es dauert jedoch gewöhnlich einige Sprints, bis das Team eine stabilere Geschwindigkeit findet. Um die Geschwindigkeit des Teams genauer zu schätzen, können wir auf die vergangenen Verfolgungsdaten des Teams zurückgreifen. Dies ermöglicht eine genauere Vorhersage, wie viele Geschichten das Team in einem Sprint abschließen kann. Für die Prognose sollte der Durchschnitt der letzten drei oder vier Sprint-Geschwindigkeiten verwendet werden.

Angenommen, ein neues Scrum-Team plant, in ihrem ersten Sprint 41 Story Points abzuschließen. Sie schließen letztendlich nur 38 Story Points ab und tragen 6 Story Points in den nächsten Sprint mit. Ihre Geschwindigkeit beträgt daher 38, wie unten gezeigt:

Scrum-Geschwindigkeit

Durchschnittliche Geschwindigkeit basierend auf der Verfolgung früherer Sprints

Wie bereits erwähnt, sollten Teams keine teilweise abgeschlossenen Arbeiten in der Geschwindigkeit berücksichtigen. Nur Benutzerstories, die als „Erledigt“ markiert sind, zählen, auch wenn nur ein kleiner Teil der Aufgabe verbleibt.

Die Geschwindigkeit basierend auf einem einzelnen Sprint ist kein sehr zuverlässiger Indikator für Prognosen. (Aber sie hilft dem Team, zu verstehen, wie viel Arbeit es in einem einzelnen Sprint übernehmen kann.) Lassen Sie uns ihren Fortschritt über weitere Sprints verfolgen.

Nun entwickelt das neue Team von Sprint 1 bis Sprint 4 weiter. Die in jedem Sprint abgeschlossenen Story Points betragen: 38, 29, 38 und 39. Die durchschnittliche Geschwindigkeit nach vier Sprints beträgt 36, wie unten gezeigt:

Scrum-Geschwindigkeit über Sprints

Dieser Durchschnitt, basierend auf vier Sprints, ist weitaus nützlicher als ein Schnappschuss nach nur einem Sprint. Es ist leicht vorstellbar, dass, wenn das Backlog bereits mit geschätzten Benutzerstories versehen ist, wir diese Geschwindigkeit zur Prognose verwenden können. Wir können vorhersagen, wie schnell das Team die gesamte Arbeit abschließen wird. Wir können fundierte Vermutungen darüber anstellen, welche Funktionen wir in der nächsten Version liefern können.

Geschwindigkeitsdiagramm

Wenn ein Scrum-Team mehrere Sprints abgeschlossen hat, kann das Team den Geschwindigkeitsbericht zur Prognose von Release- und Produktabschlussterminen nutzen und zukünftige Projekte besser planen. Auf Basis der Geschwindigkeit aus früheren Sprints, wie im Bericht dargestellt, können Sie Folgendes erreichen:

• Verfolgen Sie die Menge der Arbeit, die Ihr Team in jedem Sprint abgeschlossen hat.
• Wenn die Zusammensetzung Ihres Teams und die Dauer der Sprints unverändert bleiben, schätzen Sie ab, wie viel Backlog-Arbeit Ihr Team in zukünftigen Sprints bewältigen kann.

Basierend auf dem oben genannten Beispiel zeigt das Geschwindigkeitsdiagramm die Menge der Arbeit, die das Scrum-Team in jedem der 4 Sprints abgeschlossen hat:

Scrum-Geschwindigkeitsdiagramm