Warum Sie die Sprint-Geschwindigkeit Ihres Teams messen sollten

Wenn die Sprint-Geschwindigkeit richtig gemessen wird, kann sie Ihnen helfen, die Arbeitsbelastung Ihres Teams genau einzuschätzen, die Sprint-Planung zu vereinfachen und Projektmanagern dabei zu helfen, den Überblick über ihre Projekte zu behalten.

Was ist Sprint-Geschwindigkeit?

Die Sprint-Geschwindigkeit ist ein Maß dafür, wie viel ein Agile-Team während eines normalen Sprint-Zyklus produzieren kann. Sie verwenden zwei Hauptvariablen, um die Sprint-Geschwindigkeit zu berechnen: wie viel Arbeit Ihr Agile-Team erledigt hat und wie lange es gedauert hat, diese Arbeit abzuschließen.

Es ist wichtig zu beachten, dass die Sprint-Geschwindigkeit eine beschreibende Kennzahl ist und nicht als Erfolgskennzahl verwendet werden sollte. Die Sprint-Geschwindigkeit sollte nicht als etwas betrachtet werden, das „verbessert“ werden muss. Es ist eine harte Metrik, um zu beschreiben, wie viel Arbeit Ihr Team innerhalb eines Sprints erledigen kann. Während Sie die Sprint-Geschwindigkeit konsequent messen sollten, sollte sie nicht als Erfolgskennzahl betrachtet werden. Wenn ja, kann Ihr Team überlastet werden. Das Ziel des Verständnisses Ihrer Sprint-Geschwindigkeit ist es, die Kapazität Ihres Teams zu kennen, nicht, diese Kapazität zu erhöhen.

So berechnen Sie die Sprint-Geschwindigkeit

Sie können die Sprint-Geschwindigkeit mit einer einfachen mathematischen Gleichung berechnen: Dividieren Sie die Anzahl der Backlog-Einträge (oder Story Points, wenn Ihr Team diese verwendet) durch die Gesamtlänge Ihres Sprints in Tagen.

Wenn Ihr Team beispielsweise 60 Backlog-Einträge hat und die durchschnittliche Sprint-Dauer 2 Wochen beträgt, würde die Gleichung wie folgt aussehen:

60 Backlog-Einträge/10 Tage = Sprint-Geschwindigkeit von 6

Es ist relativ einfach herauszufinden, wie viel Ihr Team in einem durchschnittlichen Sprint erledigen kann. Beginnen Sie mit einem Backlog, das viel zu viele Einträge enthält, und sehen Sie, wie viele Einträge Ihr Team in der gewünschten Sprintzeit erledigen kann. Das Ziel ist nicht, alles im Backlog abzuschließen, sondern die Arbeit, die Ihr Team erledigen kann, zu bewerten.

Eine weitere Möglichkeit, die Sie vor Ihrem ersten Sprint nutzen können, ist die Verwendung von Projektschätzungsstrategien, um vorherzusagen, wie viel Ihr Team erledigen kann. Wenn Sie nach einigen Strategien suchen, die Sie verwenden können, versuchen Sie es mit der Top-Down-Schätzung, der Drei-Punkt-Schätzung oder der analogen Schätzmethode.

Warum die Sprint-Geschwindigkeit messen?

Sie messen die Sprint-Geschwindigkeit nicht einfach nur so – es gibt praktische (und nützliche) Gründe, warum Ihr Team die Sprint-Geschwindigkeit messen sollte. Hier nennen wir Ihnen einige Beispiele.

• Es vereinfacht die Sprint-Planung. Für Product Owner und Scrum Master kann die Kenntnis der Sprint-Geschwindigkeit Ihres Teams die Sprint-Planung erleichtern. Wenn Sie die durchschnittliche Sprint-Geschwindigkeit Ihres Teams kennen, ist es einfacher, die richtigen User Stories aus dem Product Backlog auszuwählen, um in diese Iteration zu gelangen, ohne Ihr Entwicklungsteam zu überlasten.

• Umgang mit Erwartungen der Beteiligten. Wenn Ihre Stakeholder nach einem Zeitplan für eine bestimmte User Story fragen oder wenn sie versuchen, vor dem Ende des Sprints etwas hinzuzufügen, verstehen Sie als Product Owner, wie sich diese Änderung auf die Leistung Ihres Teams auswirken kann, basierend auf der Sprint-Geschwindigkeit.

• Sie signalisiert potenzielle Probleme. Wenn Sie die Sprint-Geschwindigkeit regelmäßig verfolgen, können Sie die durchschnittliche Geschwindigkeit konsistenter messen. Wenn Sie einen plötzlichen Rückgang der Geschwindigkeit feststellen, dann wissen Sie, dass es ein potenzielles Problem gibt, wie zum Beispiel eine unvollendete Abhängigkeit, die gelöst werden muss, bevor Sie mit dem nächsten Sprint fortfahren.

So visualisieren Sie die Sprint-Geschwindigkeit

Die Möglichkeit, die Sprint-Geschwindigkeit auf einen Blick zu sehen und zu messen, kann denjenigen, die an einem agilen Projekt arbeiten, helfen, schnell zu verstehen, wie ihr Team abschneidet. Während des Sprints können sie jederzeit einen Blick auf ein Diagramm werfen und den aktuellen Fortschritt des Teams sehen. 

Je nachdem, was Sie für Ihren Sprint visualisieren möchten, gibt es verschiedene Arten von Velocity-Diagrammen, die Sie verwenden können. Hier sind einige Beispiele:

Einfaches Velocity-Diagramm

Ein einfaches Velocity-Diagramm ist ein Balkendiagramm, das zwei Hauptfaktoren vergleicht: die prognostizierte Menge an Arbeit, die Ihr Entwicklungsteam in einem Sprint erledigen kann, und die tatsächliche Arbeit, die in einem Sprint erledigt wird. 

Die X-Achse des Diagramms zeigt verschiedene Sprints, während die Y-Achse die Anzahl der Story Points oder User Stories anzeigt.

Wenn Sie sich das visuell ansehen, ist es leicht zu erkennen, wie viel Ihr Team im Durchschnitt in einem bestimmten Sprint im Vergleich zum geschätzten Betrag erledigen kann.

Burndown-Diagramm

Ein Burndown-Diagramm schätzt die Menge an Arbeit, die Ihr Team erledigen muss, und vergleicht sie mit der Zeit, die Sie im Sprint noch haben. Während der Sprint fortschreitet, besteht das Ziel darin, dass sich die Graphenlinie Null nähert. 

Wenn Sie eine Schätzung der Geschwindigkeit Ihres Teams haben, können Sie diese in Ihrem Burndown-Diagramm darstellen und sehen, wie Ihr Team im Vergleich zur idealen Geschwindigkeitslinie abschneidet. Im obigen Beispiel können Sie sehen, wie früh im Sprint das Team in der Lage war, mehr Arbeit als erwartet aus der Ideallinie zu erledigen. Schließlich nahm die Arbeitsleistung des Teams ab, aber es erreichte trotzdem das Endziel. 

Burnup-Diagramm

Ein Burnup-Diagramm ist das genaue Gegenteil eines Burndown-Diagramms. Dieses Diagramm enthält in der Regel zwei Linien: die tatsächlich abgeschlossene Arbeit und das ideale Ziel, das Ihr Team erreichen soll. Das ideale Ziel ist in der Regel eine horizontale Linie über das Diagramm, während die tatsächliche Arbeit kontinuierlich wächst, um die Ziellinie im Laufe der Zeit zu erreichen.

Tipps zur Regulierung der Sprint-Geschwindigkeit Ihres Teams

Wenn Sie bemerken, dass die Sprint-Geschwindigkeit Ihres Teams inkonsistent ist, könnte das ein Zeichen dafür sein, dass Sie die Geschwindigkeit Ihres Teams regulieren müssen. Eine gleichbleibende Sprint-Geschwindigkeit ist wichtig, da Sie so die regelmäßige Leistung Ihres Teams leicht erkennen können. Inkonsistenzen zeigen, wenn etwas nicht stimmt.

Zum Beispiel hatten vier Ihrer letzten Sprints Sprintgeschwindigkeiten von 4,5, 7, 5 und 3. Ihre durchschnittliche Sprint-Geschwindigkeit liegt in der Regel bei etwa 6. Die Inkonsistenz der Sprint-Geschwindigkeit kann ein Indikator für ein größeres Problem sein. Die Regulierung der Sprint-Geschwindigkeit Ihres Teams bedeutet, dass Sie versuchen, die Sprint-Geschwindigkeit von Sprint zu Sprint konstant zu halten.

Hier sind ein paar Tipps, wie Sie die Sprint-Geschwindigkeit Ihres Teams regulieren können.

User Storys klären

Eine Sache, die dazu beitragen kann, die Sprint-Geschwindigkeit Ihres Teams zu stabilisieren, ist sicherzustellen, dass User Stories klar und leicht verständlich sind, bevor der Sprint beginnt. Eine User Story ist eine kurze Beschreibung einer Softwarefunktion, die aus der Perspektive des Endnutzers geschrieben wird. Diese User Stories sind oft an Einträge in einem Backlog angehängt. Dies stellt sicher, dass sich Scrum-Team- oder Projektteammitglieder auf die Arbeit konzentrieren können, die sie erledigen müssen, anstatt Zeit damit zu verbringen, Stakeholder für weitere Details zu suchen. Dies kann dazu beitragen, Ihre Geschwindigkeit zu erhöhen, indem Sie die Zeit Ihres Teams auf die Arbeit konzentrieren, die am wichtigsten ist.

Konsistenz sicherstellen

Wenn die Geschwindigkeit Ihres Teams inkonsistent ist, ändern Sie möglicherweise zu viele Variablen von Sprint zu Sprint. Tauschen Sie beispielsweise verschiedene Teammitglieder aus Ihrem Entwicklungsteam aus? Die Zusammensetzung des Teams kann die Menge an Arbeit verändern, die Ihr Team leisten kann. 

Hier sind einige weitere Variablen, die sich auf Ihre Sprint-Geschwindigkeit auswirken können:

• Sprint-Länge

• Erhöhung der Story Points

• Änderung der Prozesse

Legen Sie eine einheitliche Definition von „erledigt“ fest

Es ist wichtig, dass jeder in Ihrem Team ein klares Verständnis dafür hat, was es bedeutet, wenn eine User Story „erledigt“ oder abgeschlossen ist. Dies ist ein wichtiger Aspekt des Scrum-Frameworks, der häufig auch in anderen agilen Methoden verwendet wird. 

Wenn Ihr Team eine klare Definition dafür hat, was es bedeutet, dass eine User Story abgeschlossen ist, kann es genauer abschätzen, wie viel Arbeit mit jeder einzelnen verbunden ist. Dies wiederum führt zu genaueren Projektschätzungen und letztendlich zu einer genaueren Sprint-Geschwindigkeit.

Veranstalten Sie eine Sprint-Retrospektive

Einer der Vorteile der agilen Methodik ist, dass es sich um einen iterativen Entwicklungsprozess handelt. Das bedeutet, dass es am Ende jedes Sprints eine Gelegenheit gibt, über den vergangenen Sprint nachzudenken und zu sehen, was gut gelaufen ist und was nicht. Ein Sprint-Retrospektive-Meeting ist genau dafür gedacht – ein Meeting, das sich der Reflexion über den vergangenen Sprint widmet und wie man sich für den nächsten Sprint verbessern kann.

Ziel ist es, sich kontinuierlich zu verbessern. Während Ihr Team verschiedene Sprints durchläuft, sollte es die Erkenntnisse aus vergangenen Sprints auf zukünftige Sprints anwenden. Dies gibt Ihrem Team die Möglichkeit, Prozesse zu verändern, um sich kontinuierlich zu verbessern.