Wer anfängt agil zu arbeiten, fragt sich früher oder später, ob es sinnvoll sein könnte, die Arbeit irgendwie zu schätzen. Oder von außen kommen Frage, etwa, wie das denn jetzt ohne Meilensteinplan bis Ende übernächsten Jahres laufen soll…
Arbeit realistisch einschätzen
Wir antworten da gern „Ja, schätzen ist sinnvoll, wenn es dem Team hilft!“ und zwar bei diesen beiden Anforderungen:
#1 Als Team sind wir in der Lage die Menge Arbeit die im Sprint geleistet werden kann realistisch abzuschätzen, um
- sicherzustellen, dass die Qualität nicht leidet, weil sich das Team überlastet
- der Product Ownerin und Stakeholdern zu ermöglichen, Entscheidungen auf der Basis von Prognosen zu treffen
#2 Als Team sind wir in der Lage jederzeit eine Prognose abzugeben, ob die Ziele des Sprints erreicht werden können, um
- bei Problemen frühzeitig zu reagieren
- als Team unsere Energie auf die Fertigstellung der zentralen Anforderungen zu fokussieren
- der Product Ownerin und Stakeholdern zu ermöglichen, frühzeitig zu reagieren
Die Einträge des Product Backlogs sollten also stets geschätzt sein, um sicherzustellen, dass alle ein gemeinsames Bild von den Anforderungen haben, Risiken und Unklarheiten frühzeitig erkannt werden können Entscheidungen auf der Basis von guten Prognosen gemacht werden können.
Die Statistik im Blick
Dabei hilft es ein paar Statistiken zu beobachten:
Anteil ungeschätzter Backlogeinträge im Sprint (/Backlog)
- Sind die Backlogeinträge angemessen vorbereitet?
- Haben wir überhaupt schon eine Basis für Prognosen?
- Ungeschätzte Backlogeinträge sollten die Ausnahme sein
Team-Velocity (Storypoints durch Anzahl MA & Tage)
- Ziel ist ein möglichst stabiler Wert über die Zeit
- Eine schwankende Velocity kann ein Indikator für eine hohe Unsicherheit bei den Schätzungen sein und/oder Störungen bei der Arbeit im Sprint
Anzahl von Stories (durch Anzahl MA & Tage) und Verteilung der Storygrößen
- Ziel ist ein im Regelfall stabiler Wert über die Zeit
- Schaffen wir es eine gute Größe von Anforderungen zu finden, die nicht zu detailliert sind und sich gut bewältigen lassen?
Anzahl entfernter/nachgezogener/nicht abgeschlossener Stories
- Sollte möglichst bei 0 sein.
- Stories sollten nicht angefangen werden, wenn sie nicht abgeschlossen werden können. Um das durchzuhalten, dürfen Stories nicht zu groß sein.
- Nachgezogene und entfernte Stories gleichzeitig sind ein Warnsignal!
Sprint-Burndown (Aufgaben und Stories)
- Schließen wir Aufgaben zuverlässig ab, schließen wir die Stories zuverlässig ab?
- Sind die Aufgaben klein genug, so dass wir den Fortschritt im Sprint tatsächlich auch einschätzen können?
