Die agile Community diskutiert das Thema “Schätzen” immer wieder. Dabei geht es bis hin zu einer #noestimate Bewegung, die den Aufwand von Schätzungen insgesamt als “wertlos” betrachtet. Warum ich Schätzungen grundsätzlich sinnvoll finde, habe ich in bereits in meinem Blog-Beitrag “Schätzungen – muss das denn sein?” beschrieben.
In meinem Beitrag “Schätzen: Storypoints oder Stunden?” gehe ich darauf ein, warum ich eine relative Schätzung mit Story Points für sinnvoller halte, als eine Schätzung von Stunden. Aber was genau kann und sollte man mit Story Points schätzen?
Als gängige Praxis habe ich die Schätzung von Komplexität erlebt (und selbst lange vertreten) – Seibert Media beispielsweise äußert sich im Beitrag “Kontinuierliches Schätzen in agilen Projekten” dazu. Nach vielen Jahren Erfahrung damit, komme ich mittlerweile zu dem Schluss, dass eine Schätzung nach Komplexität einen geringen Wert hat.
Warum schätzen wir?
Der Prozess der Schätzung selbst durch das für die Umsetzung gesamtverantwortliche Team hat einen hohen Wert, der sich aber – so wird auch die #noestimate Bewegung argumentieren – auch durch andere Fragen erreichen lässt: Eine intensive Auseinandersetzung mit den Themen sorgt für erste Umsetzungsideen, ein gemeinsames Verständnis und einen ersten Umsetzungsplan im Team.
Wenn dieser Wert auch durch die Diskussion anderer Fragen, als die Frage nach der geschätzten Komplexität, erreicht wird, braucht man Schätzungen dafür also nicht. Auch der Business-Wert eines Features lässt sich nicht zwingend anhand der Komplexität ablesen. Außerdem liegt die Bewertung des Business-Werts eher bei Product Owner und Stakeholder unterstützt durch das Team. Den Business-Wert zu schätzen hat Sinn, folgt aber anderen Regeln als eine übliche Team-Schätzung und verfolgt ein anderes Ziel.
Wofür hat eine Team-Schätzung dann dennoch Sinn?
Der Wert von Schätzungen liegt aus meiner Sicht darin, die kurz-, mittel- und langfristige Planung zu vereinfachen. Durch eine Schätzung wird
- eine Prognose für die Umsetzungszeitpunkte von Funktionalitäten möglich.
- die zeitliche Auswirkung von Repriorisierung überschaubarer.
- Kosten/Nutzen von Funktionalitäten sichtbar.
- es möglich, den Inhalt von Anforderungen vor dem Aufwandshintergrund mit dem Team gemeinsam zu formulieren um auf der Basis kleinstmögliche Lösungen zu konzipieren.
Was müssen wir dafür schätzen?
Die Schätzung von Komplexität gibt uns keinen verlässlichen Aufschluss über die Umsetzungsdauer und damit über die Kosten einer Umsetzung: Ein hohes Maß an Komplexität wird wahrscheinlich auch zu einer hohen Umsetzungsdauer führen. Ein geringes Maß an Komplexität ist aber keine Garantie für eine geringe Umsetzungsdauer – zum Beispiel bei einfachen Aufgaben mit einem hohen manuellen Aufwand, deren Automatisierung zu aufwändig wäre oder sich aus anderen Gründen nicht lohnt.
Das heißt: Nur der Aufwand kann Aufschluss über die Dauer einer Umsetzung geben und nur davon lassen sich die Kosten ableiten. Der hohe Wert der Schätzung als Planungsgrundlage und für eine Kosten/Nutzen Betrachtung kann also nur erreicht werden, wenn in der Schätzung nicht die Komplexität, sondern der Aufwand betrachtet wird.
Hinzu kommt, dass Komplexität ein schwammiger Begriff ist, der die ohnehin schon unscharfe Schätzung noch ungenauer macht und die Diskussionen während der Schätzung innerhalb des Teams weiter erschwert.
Wie schätzen wir?
Wenn Aufwand als zu schätzende Größe besser, weil relevanter und einfacher ist, als Komplexität, warum gibt es dann keine Rückkehr zu einer reinen Aufwandsschätzung nach absoluten Stunden oder Tagen? Warum ist eine relative Betrachtung des Aufwands von Features gegenüber dem Aufwand anderer Features besser, als eine absolute Zeit-Betrachtung?
Relativer Aufwand ist leichter abzuschätzen als absoluter Aufwand. Stellt man zwei unterschiedlich hoch mit Erbsen gefüllte Tassen nebeneinander ist es einfacher zu sagen, ob ein Glas im Verhältnis zum anderen Glas gleich voll oder doppelt so voll oder nur ein drittel so voll ist, als die genaue Anzahl der Erbsen zu bestimmen. Die absoluten Zahlen können auf Basis gemessener tatsächlicher Werte genannt werden. Die Schätzung geht schneller und ist im Mittel zuverlässiger.
Was ist das Ergebnis?
Durch eine relative Schätzung des Aufwands mit Storypoints über mehrere Iterationen hinweg ergibt sich eine Zahl, wie viel Arbeit ein Team im Durchschnitt in einer Iteration schafft. Diese Zahl lässt sich für zeitliche Prognosen verwenden und umrechnen auf die Kosten pro Storypoint. Möglich werden Diskussionen mit dem Produktverantwortlichen, ob die Fertigstellung eines Features zu einem ungefähren Zeitpunkt ausreichend ist und ob die wahrscheinlichen Kosten für die Umsetzung dem Nutzen gerecht werden.
Das Ergebnis der Betrachtung des relativen Aufwands sind weiterhin Schätzungen. Durch die Betrachtung der in der Vergangenheit gemessenen Aufwandswerte (wie viel hat ein Team in der Vergangenheit pro Iteration geschafft) sind sie zuverlässiger, als subjektiv wahrgenommene Komplexität von Aufgaben. Außerdem führen Diskussionen über relativen Aufwand schneller zu Schätzergebnissen, als die Betrachtung der viel schwerer zu greifenden technischen Komplexität.
Wichtige Ergänzungen
Das Ziel einer relativen Schätzung nach Aufwand ist eine gute Planbarkeit. Damit ist das vorrangige Ziel des schätzenden Teams auch nicht, die Anzahl der Storypoints pro Sprint zu steigern, sondern möglichst gleich zu halten und den geplanten Umfang in einer Iteration auch zu erreichen.
Ein in Storypoints relativ geschätzter Aufwand liefert also keine Aussage über die Effizienz eines Teams oder deren Steigerung. Eine möglichst gleichbleibende Zahl pro Sprint ist ein hoher Wert, da er die Planbarkeit verbessert. Außerdem ist auch diese Art der Schätzung nicht über unterschiedliche Teams hinweg gültig oder vergleichbar.
Was bedeutet das für die Schätzung?
- Das umsetzende Team schätzt die Aufwände.
- Es wird alles geschätzt, was in den Sprint geplant einfließt (auch mögliche Themen aus Technik und Konzeption, die keinen direkten Kundennutzen erzeugen).
- Der Aufwand für die Umsetzung von Incidents, Bugs und weiterem, das ungeplant während einer Iteration auftaucht, wird nicht geschätzt, sondern sollte zunächst über einen angenommenen Puffer berücksichtigt werden, dessen Größe sich durch Erfahrung nach und nach besser benennen lassen wird.
Hier gibt es weitere Beiträge zum Thema “Schätzen”.
Wie ist deine Meinung zum Thema “Schätzen” – nach Aufwand oder Komplexität oder besser gar nicht?
(Das verwendete Bild ist von Felix Meyer – vielen Dank!)
