Wir machen jetzt seit 3 Jahren Scrum, werden gefühlt aber nicht schneller – Zitat eines Kunden, den ich als Agile Coach betreut habe. In solchen Situationen frage ich immer, ob es Metriken gibt, die diese These untermauern oder widerlegen. Und in einem Großteil der Fälle wird diese Frage verneint.
Die Metriken messen dabei nicht die Schnelligkeit des vermeintlich kaputten Scrum-Prozess. Sie zeigen Verbesserungspotentiale auf und helfen zu verstehen, was im eigenen Scrum-Prozess schief läuft und wie sich Änderungen auf die Zusammenarbeit auswirken.
Von Velocity und anderen Metriken
Typischerweise nutzt Scrum als Metrik die Velocity – die Anzahl der fertiggestellten Story Points in einem Sprint. Neben der Velocity gibt es jedoch noch viele weitere Metriken. Sie sind mit wenigen Schritten installiert und liefern dem Team als auch dem Management wichtige Kennzahlen zur Verbesserung, Planung und Priorisierung.
In fünf Schritten werde ich zeigen, wie man diese Metriken etabliert und anwendet.
Schritt 1: Team-Plankapazität schätzen
Die Team-Plankapazität gibt die ungefähre Zahl der Mann-Tage an, die einem Team in einem Sprint zur Verfügung stehen. Sie sollte gemeinsam vom Team vor dem Sprint-Planning geschätzt werden. Mit ihrer Hilfe bekommt das Team ein besseres Bauchgefühl, wie viel Zeit in einem Sprint tatsächlich zur Verfügung steht und kann den Sprint entsprechend besser planen. Sie berechnet sich wie folgt:
Team-Plankapazität = Sprint-Tage * Anzahl Personen im Team
Der Knackpunkt der eigentlich einfachen Formel liegt in der realistischen Auslegung von Sprint-Tage und Anzahl Personen im Team: In einem beispielsweise zweiwöchigen Sprint kann man nicht einfach von 10 verfügbaren Arbeits- bzw. Sprint-Tagen ausgehen.
Es sollten beispielsweise Meetings-, Urlaubs- und Abwesenheitszeiten abgezogen werden. Das gleiche gilt für die Anzahl der Personen: Im Idealfall sollte eine Person im Team zu 100 Prozent im Sprint arbeiten. In der Realität zeigt sich jedoch oft, dass man nicht nur am Sprint arbeitet, sondern auch an anderen Themen. Wenn sich das kurzfristig nicht ändern lässt, sollten die betroffenen Personen entsprechend mit 25, 50 oder 75 Prozent eingeplant werden; genauere Zahlen sind erfahrungsgemäß nicht nötig.
[smartblock id=“8664″]Beispiel-Matrix
Die Team-Plankapazität kann über folgende Matrix erfasst werden:
| Mo | Di | Mi | Do | Fr | Mo | Di | Mi | Do | Fr | ||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Person 1 | 0 | 8 | 8 | 8 | 8 | 0 | 8 | 8 | 8 | 8 | |
| Person 2 | 0 | 2 | 2 | 8 | 4 | 0 | 8 | 8 | 8 | 8 | |
| Person 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
| Person 4 | 0 | 4 | 4 | 4 | 4 | 0 | 8 | 8 | 8 | 8 | |
| 0 | 14 | 14 | 20 | 16 | 0 | 24 | 24 | 24 | 24 | TP=160h/20T |
Im Beispiel geht der Sprint über zwei Wochen. Der Sprintwechsel mit dem Sprint-Meeting ist Montags – entsprechend werden die Personen mit „0“ eingeplant. Eingetragen werden die Stunden pro Tag, an denen planmäßig am Sprint gearbeitet werden kann. Schnell zeigt sich: Von den theoretisch 36 verfügbaren Mann-Tagen (4 Personen * 9 Tage) im Sprint können tatsächlich nur 20 Tage aktiv genutzt werden.
Die Team-Plankapazität muss nicht hundertprozentig exakt sein oder nachträglich korrigiert werden – letztendlich ist sie eine Schätzung und hilft dem Team als auch dem Product Owner, den Sprint nicht mit einem idealen, sondern mit einem realistischen Blick auf die verfügbaren Ressourcen zu planen.
Schritt 2: Arbeit sichtbar machen – auch das Tagesgeschäft
Die Schwäche von Scrum ist die Unplanbarkeit von betrieblichen Tätigkeiten – das Tagesgeschäft. Auf dem Scrum-Board sind in der Regel die im Sprint-Meeting eingeplanten User Stories und die damit verbundenen Tasks sichtbar; alles andere läuft unsichtbar am Sprint vorbei und wird unterschätzt.
Je nach Aufkommen dieser Aufgaben haben sie einen massiven Einfluss auf die Stabilität eines Sprints; insbesondere wenn sie sich thematisch nicht aus dem Team herauslösen lassen. Die Symptome sind beispielsweise eine stark schwankende Velocity, nicht abgeschlossene und schwer planbare Sprints oder das dumpfe Gefühl, dass man die ursprünglich geplanten User Stories eigentlich hätte schaffen müssen.
Das Tagesgeschäft sollte in Form von Tasks in einer eigenen Swimlane auf dem Scrum-Board sichtbar gemacht werden. Meine persönliche Faustformel lautet: Alles, was länger als 15-30 Minuten dauert, sollte als Task erfasst werden. Durch das Sichtbarmachen der Arbeit erhält das Team ein Gefühl dafür, wo die Arbeitszeit investiert wird. Bei der nächsten Schätzung der Team-Plankapazität kann das Tagesgeschäft als ungefährer Durchschnittswert berücksichtigt werden. Letztendlich führt dieses Verständnis wie die Team-Plankapazität zu realistisch geplanten Sprints und damit zur einer besseren Planungssicherheit.
Schritt 3: Alles zählen
Eine einfache Fleißarbeit, die während des Sprints erledigt werden kann: alles zählen. Dabei sollte grundsätzlich geklärt werden:
- Wie viele von User Stories losgelösten, ungeplanten Tasks hatten wir im Sprint?
- Mit wie vielen User Stories startet und endet der Sprint (wie viele sind abgeschlossen)?
- Mit wie vielen Tasks starten User Stories und mit wie vielen Tasks enden sie?
Am Ende eines Sprints können sich aus den gesammelten Zahlen beispielsweise folgende Fragen ergeben:
- Warum haben wir so viele von User Stories losgelöste Tasks? Wie können wir sie vermeiden?
- Warum ziehen wir User Stories nach, obwohl andere noch nicht abgeschlossen sind?
- Warum enden User Stories mit mehr Tasks als ursprünglich gestartet? Fehlen uns Einsichten?
- …
Die Sprint-Retrospektive bietet sich an, diese und weitere sich aus den Zahlen ergebende Fragen zu klären und entsprechende Maßnahmen abzuleiten. Das Reflektieren dieser simplen Metriken verhilft dem Team zu einer kritischeren Betrachtungsweise der eigenen Arbeitsorganisation sowie deren Verbesserung.
Schritt 4: Lead- und Cycle-Time erfassen
Die Kern-Metriken von Kanban können auch in Scrum verwendet werden. Unter Lead-Time versteht man die Zeitspanne von der Idee bis zur Fertigstellung einer User Story bzw. eines Tasks. Die Cycle-Time erfasst die Zeitspanne von Arbeitsbeginn bis zur Fertigstellung. Sowohl die Lead- als auch die Cycle-Time sollte bei allem, was auf dem Scrum-Board erfasst wird, gemessen werden. Das heißt bei User Stories, deren Tasks sowie bei ungeplanten Tasks, die losgelöst von User Stories bearbeitet werden.
Die sich ergebenden Zahlen bzw. Zeiträume sind vor allem zum Hinterfragen der aktuellen Planung und Priorisierung sowie deren Verbesserung hilfreich. So könnte sich beispielsweise herausstellen, dass ungeplante Tasks eine Lead-Time von durchschnittlich drei Tagen und eine Cycle-Time von zwei Tagen haben. Sie sind zeitlich betrachtet also relativ teuer und sollten vermieden werden.
Es könnte sich auch zeigen, dass die Cycle-Time einer User Story im Schnitt fünf Tage beträgt. Es ergibt also vermutlich keinen Sinn, im Sprint-Planning 10 User Stories zu ziehen, wenn in Verbindung mit der Team-Plankapazität absehbar ist, dass nur fünf zu schaffen sind.
Unterm Strich erhält das Team mit dem Erfassen der Lead- und Cycle-Time seiner Aufgaben ein mächtiges Tool, um die mit der Arbeit verbundenen zeitlichen Aufwände wesentlich besser einschätzen zu können.
Schritt 5: Dauerhaft erfassen, analysieren und reflektieren
Die Metriken sind schnell erfasst. Doch nun ist Disziplin gefordert: Die Metriken müssen dauerhaft erfasst, analysiert und reflektiert werden. Und das nicht nur am Sprint-Ende in einer Retrospektive, sondern täglich. Vor allem der Scrum Master und der Product Owner sollten ein Auge auf die Metriken haben und gemeinsam mit dem Team Kennzahlen ableiten, mit denen die Stabilität und die Performance des Scrum-Prozesses sichtbar gemacht werden können.
Eine Kennzahl ist zum Beispiel – wie bereits zu Beginn erwähnt – die Velocity. Andere Kennzahlen können zum Beispiel die durchschnittliche Team-Plankapazität, Bearbeitungszeit von ungeplanten Tasks und User Stories, usw. sein. Diese Kennzahlen sollten im Blickfeld aller Projektbeteiligten sein, um mit dem gegebenen Ist-Zustand eine realistische Planung zu erreichen.
Gemeinsames Verständnis
Wichtig ist auch ein gemeinsames Verständnis der Zahlen: Sie sind nicht zwingend absolut, eher Richtwerte und zeigen vor allem Tendenzen zur Orientierung auf – persönlich rate ich, sie wie einen Wetterbericht zu lesen. Daraus ableitend kann man sich gemeinsam überlegen, welche Maßnahmen durchzuführen sind, um den Scrum-Prozess auf Geschwindigkeit zu optimieren. Die Kennzahlen sowie die Metriken werden sofort aufzeigen, ob die Maßnahmen erfolgreich sind oder nicht.
Welche Erfahrungen habt ihr mit Metriken im Scrum-Prozess gemacht? Welche Metriken nutzt ihr?
Schreibe einen Kommentar