Story-Estimation in Scrum: Zeitaufwand oder Story Points schätzen?
In der Zusammenarbeit mit Unternehmen, die Scrum einsetzen, begegnet mir immer wieder die Frage nach der “richtigen” Art und Weise, Stories zu schätzen. Manche Teams schätzen Zeit, manche Story Points, andere T-Shirt-Größen. Die Beobachtungen, die ich bei den unterschiedlichen Ansätzen gemacht habe, fließen hier in eine Gegenüberstellung von Schätzen in Zeitaufwand und Schätzen in Story Points ein.
Zeitschätzung von User Stories
Das Schätzen der Zeit ist naheliegend, und viele Menschen, mit denen ich arbeite, nennen das selbstverständlich. Schließlich will man wissen, wie viel Zeit erforderlich sein wird, um eine Aufgabe zu erledigen. Das ist die Basis von Planung, wie sie sie kennen.
Möchte man zu einer gegebenen Aufgabe wissen, wie lange es dauert, sie zu erledigen, spielen viele Faktoren eine Rolle. Ein Faktor, der immer dabei ist: Wer bearbeitet die Aufgabe? Ein Entwickler, der viel Erfahrung und die richtigen Skills besitzt, wird die Aufgabe schneller erledigen als jemand, der all das nicht mitbringt. Das Schätzen der Zeit ist damit auch immer ein vorweggenommener Teil der Sprint-Planung. Wenn im Refinement einer Story A bei Bearbeitung durch einen erfahrenen Entwickler B eine Zeitschätzung von einem halben Tag herauskommt, kann man die Story für einen Sprint, in dem Entwickler B nicht zur Verfügung steht, nicht einplanen. Das Team verweist darauf, dass es sich um B’s Story handelt und sie später bearbeitet werden müsse. Die Verantwortung für die Umsetzung liegt also bei B, nicht beim Team.
Was geschieht wenn ein Sprint zu Ende geht, und das Team hat nicht alle eingeplanten Tickets erledigt. Viele Teams stellen jetzt die Frage: ”Wie können wir besser schätzen?” Oder noch schlimmer: "Was stimmt mit unserer Schätzung nicht?"
Von diesen negativen Auswirkungen des Schätzens von Zeit, aber auch des Umrechnens von anderen Größen (z.B. Story Points) in Zeit, berichtet auch Ron Jeffries in einem Video, der als "Erfinder" der Story Points gilt.
In der Folge dehnen sich Refinements aus. Es geht mehr und mehr um die allumfassende Aufklärung aller Eventualitäten, mit dem Ziel, die Schätzungen zu verbessern. Es geht um Einzelheiten der Implementierung. Besseres Schätzen, so die Überzeugung, setzt mehr Informationen voraus. Die Lead Time wächst, was weder die Stakeholder glücklich macht, noch die Produktqualität erhöht. Wenn im Refinement die Schätzungen der Teammitglieder voneinander abweichen, bemüht sich das Team seltener, Unklarheiten zu beseitigen, sondern erklärt die Abweichungen durch unterschiedliche Skills der jeweiligen Personen. “Es ist okay, wenn Entwickler C nur einen Tag schätzt, während Entwickler B eine Woche schätzt; schließlich hat C viel mehr Erfahrung.”
Zusammengefasst, ich erkenne wenige positive Fragen oder Handlungen, die aus dem Schätzen in Zeiteinheiten entstehen. Wie sieht es bei Teams aus, die Story Points verwenden?
Schätzen in Story Points
Das Schätzen in Story Points beeinflusst das Team auf eine andere Weise. Dabei verstehe ich Story Points als eine abstrakte Größe, die das Ausmaß der Story beziffert; ich verwende gerne Fibonacci-Zahlen als Schätzgrößen. Ron Jeffries spricht im oben genannten Video von "idealen Tagen"; auch das ist eine abstrakte Größe, die aufgrund der Namensgebung ein leichtes Angriffsziel für interessierte Manager ist. Nun könnte man einwenden, dass man Story Points ja in Zeit umrechnen kann und letzlich - zumindest indirekt - auch tatsächlich umrechnet. Schließlich nutzt ein Team die Story Points, um zu entscheiden, wieviel Arbeit passt in den Sprint.
Damit das nicht passiert, gilt beim Vorgang des Schätzens mit Story Points für mich eine zentrale, axiomatische Forderung:
„Die Schätzung ist immer richtig.“
Diese Prämisse ist beim Schätzen in Zeit unmöglich. Wenn ich einen Tag schätze und zwei Tage für die Arbeit brauche, ist es ausgeschlossen, die Schätzung rückblickend als richtig zu bezeichnen.
Bei Story Points ist das nicht nur möglich, sondern essentiell. Die Story Points quantifizieren die Story, nicht die für die Umsetzung erforderliche Arbeit. Teams, die so arbeiten, neigen im Refinement eher dazu, ein Verständnis der Business-Sicht und des Geschäftsbeitrags (business value) der Story zu entwickeln. Es geht darum, mit den Business-Stakeholdern eine gemeinsame Perspektive auf die Story und das dahinterstehende Ziel zu formen.
Spannend ist, was nach dem Sprint passiert. Wurde das Ziel nicht erreicht, einige zugesagte Stories nicht erledigt, stellt sich nicht die Frage, wie man das Schätzen verbessern kann; die Prämisse, die Schätzung ist immer richtig, braucht man genau in diesem Fall.
Aber welche Handlungsmöglichkeit bleibt dann? Es bleibt eine Frage, deren Beantwortung viel wertvoller ist: "Wie können wir als Team besser und schneller arbeiten?"
Aus dieser Frage können spannende Experimente für die kommenden Sprints entstehen. Vielleicht können wir Eingangskriterien für Stories (Definition of ready) einführen oder verbessern. Vielleicht bietet es sich an, die Skills im Team besser zu streuen (Cross-Funktionalität, Busfaktor). Vielleicht ist die Cycle Time die richtige Metrik, um besser zu werden. Vielleicht ist ein Work-in-progress-Limit die richtige Maßnahme, um das Sprintziel zuverlässiger zu erreichen. Vielleicht können wir Test-driven arbeiten, um vor dem Sprintende nicht im Testing-Stau zu stehen. Vielleicht können wir teamübergreifende Abhängigkeiten gemeinsam planen, um nicht mitten im Sprint blockiert zu sein.
Fazit
Der Weg zum exzellenten Team führt nicht über bessere Antworten, sondern über bessere Fragen. Schätzen in Story Points in Verbindung mit der Prämisse “Die Schätzung ist immer richtig” öffnen den Raum, um bessere Fragen zu stellen.
Ich bin an Meinungen und Feedback zu diesem Text interessiert. Was denkst Du über meinen Standpunkt? Welcher Teil des Textes war für Dich nützlich? Bitte gib mir Feedback auf LinkedIn.
Übrigens freue ich mich auch über Meinungen zum Thema #noestimates ;-)