Die Arbeit ist am Ende des Sprints unvollendet. Kommt das regelmäßig vor? Bekommen Sie Kommentare dazu? „Velocity“ gibt Ihnen Einblick in Ihre Planung und hilft Ihnen, enttäuschte Kunden und Kollegen zu vermeiden.
Die wörtliche Übersetzung von Velocity ist „Geschwindigkeit“. In der agilen Arbeitsweise bedeutet Velocity aber vor allem die Menge an Arbeit, die ein Team in einer bestimmten Zeitspanne, z. B. pro Sprint oder pro Monat, erledigen kann. Wenn Sie als Team eine gute Vorstellung davon haben, wie viel Arbeit Sie pro Monat erledigen können, hilft das enorm, realistisch zu planen.
Velocity in der agilen Arbeitsweise, um realistisch zu planen
Wenn man die agile Arbeitsweise mit der traditionellen Wasserfallmethode vergleicht, kommt oft das Gantt-Diagramm zur Sprache. Das Schöne an einem Gantt-Diagramm ist, dass die Stakeholder einen festen Stand haben: Sie wissen genau, welcher Teil des Projekts wann fertig ist. Der große Nachteil? Die Planung wird oft angepasst, weil sich die Arbeit als schwieriger erweist als ursprünglich angenommen.
Bei Agile basiert die Geschwindigkeit auf dem, was man tatsächlich tun kann. Anstatt zu prognostizieren, wie viel Arbeit man erledigen wird, blickt man auf die Zeit zurück, um zu sehen, wie viel Arbeit man erledigt hat. Das passt perfekt zum Empirismus von Scrum: Nur was gewesen ist, weiß man mit Sicherheit. Und was Sie sicher wissen, können Sie als Schätzung für die kommende Zeit verwenden. So können Sie auch bei sich änderndem Umfang rechtzeitig signalisieren, ob es machbar ist, alles im Product Backlog innerhalb der vorgegebenen Zeit und des Budgets zu liefern.
Wie bestimmen Sie den Arbeitsaufwand?
Eine Voraussetzung für die Arbeit mit Velocity und realistischen Vorhersagen ist, dass der Umfang der gesamten Arbeit im Product Backlog geschätzt wurde, auch die großen Brocken, die Sie noch verfeinern müssen. Agile Teams verwenden zu diesem Zweck häufig Story Points: eine relative Methode zur Schätzung der Arbeit, anstelle von absoluten Einheiten wie Stunden. Die Punkte basieren auf der Fibonacci-Reihe. Relativ kleine Aufgaben erhalten z. B. 2 oder 3 Punkte. Größere Aufgaben erhalten 21, 34 oder sogar mehr als 100 Punkte.
Was „klein“ und was „groß“ ist, variiert von Team zu Team, was auch in Ordnung ist. Jedes Team verwendet seine eigene relative Verteilung von kleinen und großen Gegenständen, hängt eine Zahl daran und erstellt so eine Verteilung des Arbeitsaufwands. Sie können eine solche Aufteilung z. B. mit Hilfe des Planning Pokers oder des Swimlane Sizing vornehmen.
Wie berechnet man Velocity?
Normalerweise ist mit der Velocity eines Teams die durchschnittliche Velocity gemeint: die Menge an Arbeit (in Story Points), die ein Team im Durchschnitt in einem bestimmten Zeitrahmen abarbeiten kann. In Teams, die nach Scrum arbeiten, variiert die Geschwindigkeit von Sprint zu Sprint. Das ist ganz logisch: Je nach freien Tagen, Ihrer Laune, Krankheit und der Komplexität der Arbeit können Sie manchmal mehr und manchmal weniger in der gleichen Zeit erledigen.
Sie berechnen also die durchschnittliche Geschwindigkeit über eine Reihe von abgeschlossenen Sprints. Die Menge der Arbeit, die Sie in den letzten Monaten erledigen konnten, ist ein guter Hinweis darauf, wie viel Arbeit Sie in der kommenden Zeit erledigen können.
Angenommen, ein Team hat drei zweiwöchige Sprints abgeschlossen. Im ersten Sprint haben sie insgesamt 20 Story-Punkte auf „done“ gesetzt, im zweiten Sprint 29 und im dritten Sprint 23. Das sind durchschnittlich 24 Story-Punkte pro zweiwöchigem Sprint (20 + 29 + 23 = 72 und 72 / 3 = 24). Bei der Planung des nächsten Sprints ist es also sinnvoll, insgesamt ±24 Story Points einzuplanen: Auf der Grundlage der Vergangenheit ist das die realistischste Schätzung dessen, was das Team derzeit liefern kann.
Anhand der durchschnittlichen Geschwindigkeit können Sie auch abschätzen, wie viele Sprints Sie noch benötigen, um die gesamte Arbeit im Backlog abzuschließen. Wenn die Punkte in einem Product Backlog auf insgesamt 347 Story Points geschätzt werden, werden Sie wahrscheinlich etwa 15 Sprints benötigen, um die gesamte Arbeit abzuschließen (347 / 24 = 14,5). Je weiter man in das Projekt einsteigt, desto realistischer wird diese Vorhersage, da die Geschwindigkeit zuverlässiger wird und die Punkte im Product Backlog immer umfangreicher werden.
Verwendung von Velocity in Kanban
Velocity ist eine Methode, um den Durchsatz eines Kanban Teams auszudrücken. Während ein Scrum Team Sprints als Zeitraum verwendet, um die durchschnittliche Velocity zu berechnen, können Sie als Kanban Team eine beliebige Timebox verwenden. Achten Sie aber darauf, dass Sie die Timebox nicht zu groß wählen. Letztendlich wollen Sie auf der Grundlage Ihrer Geschwindigkeit die Arbeit für die kommende Zeit planen können. Und wenn Sie agil arbeiten, versuchen Sie, diese Timebox so kurz wie möglich zu halten.
Anhand der durchschnittlichen Velocity kann ein Kanban Team während eines Replenishment Meetings bestimmen, wie viel Arbeit es aus dem Backlog in die „to do“ Spalte verschieben kann. Obwohl die Verpflichtung für die Arbeit in der To-Do-Spalte weniger streng ist als in einem Scrum Team, ist es sinnvoll, die Größe der Spalte überschaubar zu halten. Auf diese Weise behalten Sie einen nützlichen und angenehmen Überblick.
Velocity als Leistungsfaktor in der agilen Arbeitsweise
Quizfrage: Ein Scrum Master betreut zwei Teams, die sich in jeder Hinsicht ähnlich sind. Die gleiche Anzahl von Entwicklern, ähnliche Fähigkeiten und beide Teams arbeiten an einem ähnlichen Produkt in vierzehntägigen Sprints. Es gibt jedoch einen offensichtlichen Unterschied: Team A hat eine Velocity von 48 Punkten pro Sprint, während Team B eine Velocity von 27 Punkten pro Sprint hat. Welches Team schneidet besser ab?
A ) Team A, weil mehr Punkte mehr Wert bedeuten
B ) Team B, weil weniger Punkte weniger Komplexität bedeuten
C) Das kann man anhand der Velocity nicht sagen
Die richtige Antwort ist natürlich C. Da Velocity für Geschwindigkeit steht und eine höhere Velocity oft als „besser“ empfunden wird, ist man schnell der Meinung, dass ein Team mit einer höheren Velocity besser abschneidet. Aber die Anzahl der Punkte, die ein Team einem Punkt zuweist, ist immer subjektiv. Während ein Team einem Element 8 Story-Punkte gibt, kann ein anderes Team ihm 5 oder 13 Punkte zuweisen.
Die Anzahl der Punkte hat also an sich keine Bedeutung. Sie bedeutet lediglich, dass ein bestimmtes Element mit vielen Punkten von einem Team als „mehr Arbeit“ angesehen wird als Elemente mit weniger Punkten. Die durchschnittliche Geschwindigkeit ist daher innerhalb eines agilen Teams von großem Wert, sagt aber im Vergleich zu anderen Teams nichts aus.
