Agile Metriken Teil 1: Einstieg in die Grundlagen

Jeder, der in einem agilen Umfeld arbeitet, kennt eines der wichtigsten Prinzipien: "Funktionierende Software ist das wichtigste Fortschrittsmaß". Ja, das ist es. Was uns nicht daran hindert, weitere Metriken einzusetzen, um den Fortschritt eines Teams zu erkennen und darzustellen. Welche Möglichkeiten stehen dafür zur Verfügung? Worauf müssen wir dabei achten? Meine wichtigsten Erkenntnisse dazu aus der Praxis als Scrum Master habe ich in einer zweiteiligen Artikelserie zusammengefasst.

Teil 1 beschäftigt sich mit Grundlagen, Story Points, Velocity und der Releaseplanung.

In Teil 2 gehe ich auf mögliche Varianten ein, den Fortschritt während eines Sprints zu ermitteln, insbesondere die Vor- und Nachteile der unterschiedlichen Messmethoden.

Grundlagen

Story Points und Velocity sind inzwischen bekannte Begriffe. Story Points werden als abstrakte Größe dargestellt, angelehnt an die Fibonacci-Reihe: 1, 2, 3, 5, 8, 13, 20, 40, 100. Die Velocity zeigt wie viele Story Points ein Team innerhalb eines Sprints umsetzen konnte.

• Story Points: Komplexität, die sich aus Aufwand, Unsicherheit und Risiko zusammensetzt
• Velocity ist ein empirisches Maß der Produktivität eines Teams in der Vergangenheit.
  
  

Ziel eines Teams ist es, die optimale Velocity zu erreichen: hohe Effektivität, bei der es ausreichend Zeit für Refactoring und Verbesserungsmaßnahmen aufwenden kann.  Eine maximale Velocity wäre kontraproduktiv, da sie nur auf kurzfristigen Erfolg ausgerichtet ist und Aktivitäten, die dem Team langfristig helfen, unterblieben.

Mit Hilfe der durchschnittlichen Velocity eines Teams kann der Product Owner Annahmen darüber treffen, bis wann ein bestimmter Fertigstellungsgrad des Product Backlogs erreicht werden kann.

Dabei ist folgendes wichtig:

• Story Points sind ein teamindividueller Wert (abstrakte Größe!) und daher kann man die Velocity verschiedener Teams nicht miteinander vergleichen. 
• Story Points drücken Annahmen über Komplexität aus und daher kann man sie nicht in den geschätzten Aufwand von Personentagen umrechnen.
  
  

Manager lieben Kennzahlen, Grafiken und Dashboards. Den Erledigungsgrad eines Projekts oder Arbeitspaketes als Prozentwert dargestellt, die offene Menge an Arbeit im Detail geschätzt. Es gibt ihnen das Gefühl von Sicherheit, das sie bei Projekten schmerzlich vermissen (einmaliges Vorhaben, komplex, zeitlich limitiert; Vorhersehbarkeit also naturgemäß begrenzt).

Gerade bei der Einführung agiler Methoden werden daher auf Managementebene erreichte Story Points und ermittelte Velocity oft missverstanden, es wird versucht zu viel oder Falsches daraus abzuleiten oder hinein zu interpretieren. Don’t do it!

Das Konzept dahinter ist inhärent einfach. Manager sollten es dabei belassen und sich lieber darum kümmern, dass Teams selbstorganisiert Entscheidungen treffen können; ihnen das Umfeld geben, das sie benötigen; sie bei der Lösung von Impediments unterstützen und sich der agilen Prinzipien in der Organisation annehmen. Das hilft dem Fortschritt in Projekten mehr als Maßnahmen, die den agilen Ideen widersprechen. 

Darstellung Velocity

• Geplant : Erreicht

Abb. Beispiel Darstellung Velocity

• Was plant das Team im Sprint, was hat es erreicht?
• Die Darstellung hilft dabei, Informationen über den agilen Reifegrad eines Teams und seine Selbstorganisation zu erhalten, wie gut es ihm gelingt, Aufgaben zu planen und timeboxed umzusetzen.
• Sie ist aussagekräftiger als ein Chart, das nur die erreichten Story Points zeigt.
• Sie hilft dabei, den Umfang zukünftiger Sprints zu planen.
• Story Points werden nur in dem Sprint gezählt, in dem sie die Werthaltigkeit der Software erhöhen (auslieferbare Software).
• Sie werden erst nach Fertigstellung, gegebenenfalls z. B. im Folgesprint (die dort auch wieder geplant wird), dazu gezählt. Velocity gleicht sich im Mittel aus.
• Zur Erinnerung: Velocity ist teamindividuell - sie ist kein KPI, sie ist nicht mit anderen Teams vergleichbar

Releaseplanung

Bis wann kann eine bestimmte Menge an fachlichen Funktionalitäten, die für eine Release geplant ist, umgesetzt werden?

Dafür benötigen wir:

• ein bewertetes Backlog (Summe Storypoints der betroffenen User Stories)
• die durchschnittliche Velocity des Teams, gegebenenfalls Von-Bis-Werte
  
  

Als Darstellung können wir dafür ein sogenanntes Burn-Up-Chart wählen:
 

Abb. Beispiel eines Burn-Up Charts

• Auf der X-Achse zeigen wir die Sprints, auf der Y-Achse die Summe der Storypoints. Der waagrechte Balken stellt den Umfang des Backlogs dar.
• Wir sehen die Ergebnisse der vergangenen Sprints. Wie viel vom Backlog wurde bis Sprint X (erster senkrechter Balken) bereits umgesetzt?
• Wir sehen, ob die Umsetzung des Scopes bis zu einem geplanten Zeitpunkt (zweiter senkrechter Balken) möglich ist. Die gepunktete Linie ab dem ersten senkrechten Balken zeigt den prognostizierten Verlauf anhand der bisherigen durchschnittlichen Velocity.
• In dem Beispiel bilden wir die Planung mit Bandbreite ab, Velocity-Von (Forecast Low) und Velocity-Bis (Forecast High).
• Der geplante Release-Termin ist Sprint 15. Im Best Case schaffen wir die Umsetzung mit Sprint 14, im Worst Case mit Sprint 16.
• Warum planen wir mit Bandbreite?
  • Weiter in der Zukunft liegende User Stories sind vom Inhalt und von der Schätzung her weniger genau als die im nächsten Sprint umzusetzenden Stories.
  • Die Summe der Storypoints pro Sprint schwankt um ein Mittelmaß. Es ist eine bestmögliche Annäherung, daher ist es realistischer mit einer Bandbreite zu rechnen: Wie viele Story Points erreicht das Team im Normalfall garantiert (Untergrenze) und welcher Wert ist in einem „guten“ Sprint realistisch (Obergrenze)?
    
    

Der Product Owner kann mit diesem Werkzeug das nächste Release planen, dafür braucht er nur eine einfache Excel-Tabelle. Wie wirkt sich ein geänderter Produktumfang oder die Anpassung der Priorisierung auf das Einsatzdatum aus? Er kann damit Planung und Ziele dem Entwicklungsteam verständlich machen und gemeinsam mit ihm Wege suchen, um einen gewünschten Releasetermin einzuhalten. Zum Beispiel: Welche Veränderung von Akzeptanzkriterien verringert die Komplexität umfangreicher User Stories und führt zu einer Neubewertung des Backlogs, die sich positiv auswirkt?

Agilität ermöglicht Flexibilität in der Planung, ausgerichtet am Business Value. Einfache Darstellungsmöglichkeiten helfen uns dabei.

In Teil 2 werde ich auf mögliche Varianten eingehen, den Fortschritt während eines Sprints ermitteln, insbesondere die Vor- und Nachteile der unterschiedlichen Messmethoden. Bleiben Sie dran!

>> "Agile Metriken Teil 2"