In fünf Schritten zu aussagekräftigen Metriken im Scrum-Prozess

5 Tipps zum Sammeln aussagekräftiger Metriken im Scrum-Prozess

Avatar von Daniel Prokscha

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:


MoDiMiDoFrMoDiMiDoFr
Person 10888808888
Person 20228408888
Person 30000000000
Person 40444408888

014142016024242424TP=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?

Avatar von Daniel Prokscha

Kommentare

3 Antworten zu „5 Tipps zum Sammeln aussagekräftiger Metriken im Scrum-Prozess“

  1. Guter Artikel! Bevor man Metriken erfasst, sollte man sich erst einmal die Frage stellen, warum man eigentlich messen will.

    Aus meiner Sicht gibt es zwei wesentliche Gründe, Metriken zu erfassen:

    1. Man möchte herausfinden/nachweisen, dass durch agiles Arbeiten eine Verbesserung eingetreten ist oder man auf dem Weg zu Verbesserungen ist:
    Für diesen Fall sollte man Metriken finden, die vor der Einführung von agilem Arbeiten schon erhoben wurden bzw. nachträglich festgestellt werden können, z.B. Kundenbewertungen, Häufigkeit von Releases, Anzahl der Bugs, etc.

    2. Man möchte Maßnahmen identifizieren, mit denen sich Teams (dann benötigt man Team-Metriken) bzw. die Organisation (Organisations-Metriken) verbessern möchte:
    Für diesen Fall lohnen sich die im Artikel erwähnten Metriken.

    Wichtig ist nur, dass man Maßnahmen zur Verbesserung identifiziert und diese regelmäßig überprüft bzw. anpasst.

  2. könnt ihr ergänzen, welche Rückschlüsse man zum Beispiel aus einer (hohen) Cycle-Time ziehen kann. Ich würde bspw. aus einer hohen Cycle-Time ableiten, dass entweder die User Stories zu groß sind oder das Team nicht mit ausreichendem Fokus an einer User Story arbeitet.

    1. @Heiko H.:
      Zunächst sollte man klären, was „hohe Cycle-Time“ bedeutet. Sind das 2 PT, 5PT oder ist die Schmerzgrenze erst bei 100 PT erreicht? Man muss sich einen Rahmen definieren, in dem man idealerweise bleiben möchte. Ansonten verfällt man schnell in einen Modus, in dem sich alles langsam anfühlt, obwohl man eigentlich gut unterwegs ist. Wenn dieser Rahmen definiert ist, kann man retrospektiv die Ursachen für die zeitliche Verzögerung von z.B. User Stories ergründen und ggü. Stakeholdern auch transparent darstellen. Erfahrungsgemäß sind die Gründe oft vielfältig und DEN Grund gibt es nicht. Manchmal lassen sich zu große Stories gar nicht vermeiden. Auch kann es Situationen geben, in denen der Fokus auf andere Prioritäten gelenkt werden muss und trotz langer Lead-Time nur tatsächliche sehr wenig Arbeitszeit zur Fertigstellung investiert wurde. Vielleicht gibt es aber auch externe oder interne Abhängigkeiten, auf die man warten muss. Oder eine Krankheitswelle fegt durch das Team. Manche Dinge kann man vielleicht ändern, andere sind gegeben. Pauschal beantworten kann man deine Frage leider nicht wirklich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.