SchätzenWer 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 er/sie wird von außen gefragt, 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?

Wenn Dir unser Blog gefällt und Du auf dem Laufenden bleiben möchtest, schreib uns kurz eine Nachricht dazu, dann bekommst Du+ alle 2 – 3 Monate unseren Newsletter mit aktuellen Beiträgen aus dem Blog, Tipps und Tricks für die agile Praxis und Veranstaltungsankündigungen z.B. zur Mini-Konferenz oder dem agilen Freitag.

Foto: Timur Saglambilek/pexels.com