Beiträge

Die #NoEstimates-Debatte: Wann Story Points helfen und wann sie schaden

Story Points sind seit über zwei Jahrzehnten die Standard-Einheit für agile Schätzungen. Dann twitterte Woody Zuill 2012 #NoEstimates, und die Diskussion hat seitdem nicht aufgehört. Das #NoEstimates-Lager sagt, Schätzung sei Verschwendung. Das Pro-Schätzungs-Lager sagt, man könne ohne sie nicht planen. Beide Seiten haben gültige Argumente, und beide übertreiben ihre Position. Hier ist, was tatsächlich standhält, wenn man über die Twitter-Debatten hinausblickt.

Was #NoEstimates tatsächlich argumentiert

Die Bewegung wird oft falsch dargestellt. Woody Zuill, Vasco Duarte und andere Befürworter sagen nicht "schätze niemals irgendetwas". Ihr Kernargument ist spezifischer:

• Der meiste Schätzaufwand führt nicht zu Entscheidungen, die besser sind als das, was man mit einfacheren Methoden erhalten würde
• Story Points werden als Verpflichtungen, Deadlines und Leistungsmetriken missbraucht
• Teams verbringen Stunden in Schätzsitzungen, die sie mit dem Erstellen von Software verbringen könnten
• Historische Durchsatzdaten (wie viele Items Sie pro Sprint fertigstellen) sagen Liefertermine zuverlässiger voraus als das Aufsummieren von Story Points

Duartes Buch #NoEstimates macht einen datengestützten Fall: Wenn Sie verfolgen, wie viele Stories Ihr Team pro Sprint abschließt und diese Stories ungefähr gleich groß sind, können Sie Liefertermine mithilfe von Monte-Carlo-Simulationen vorhersagen, ohne jemals einen Punktwert zuzuweisen. Das Argument ist nicht gegen Planung. Es geht darum, dass Story Points eine teure Art sind, Informationen zu erhalten, die man günstiger bekommen kann.

Wo #NoEstimates einen Punkt hat

Einige der Kritik trifft zu.

Story Points driften in Leistungsmetriken ab

Dies ist der häufigste Fehlermodus. Ein Manager sieht Team A 40 Punkte pro Sprint liefern und Team B 25, und schlussfolgert, Team A sei produktiver. Also beginnt Team B, seine Schätzungen aufzublähen. Innerhalb weniger Sprints messen Story Points nichts außer dem Druck, den das Team empfindet. Der Scrum Guide warnt explizit davor, aber es passiert ständig. Sobald Punkte zu einem Ziel werden, hören sie auf, als Schätzwerkzeug nützlich zu sein.

Schätzsitzungen fressen echte Zeit

Ein Team von sieben Entwicklern, das zwei Stunden damit verbringt, 20 Backlog-Items zu schätzen, kostet 14 Personenstunden. Wenn diese Schätzungen keine Entscheidungen ändern, sind das 14 Stunden Verschwendung. Für Teams mit stabilen Backlogs und vorhersehbarer Arbeit kann die Schätzzeremonie genau das werden: eine Zeremonie.

Falsche Präzision tötet gutes Urteilsvermögen

Zwanzig Minuten lang zu debattieren, ob etwas eine 5 oder eine 8 ist, ist eine echte Sache, die in echten Sprint Plannings passiert. Die Fibonacci-Folge sollte dies verhindern, indem sie Sprünge zwischen Zahlen erzwingt, aber Teams quälen sich trotzdem damit. Diese Zeit wäre besser damit verbracht, die Story in kleinere Teile zu zerlegen.

Wo #NoEstimates scheitert

Die Bewegung hat auch blinde Flecken.

Es geht von kleinen, einheitlichen Stories aus

Der "zähle einfach Stories"-Ansatz funktioniert nur, wenn Stories ungefähr die gleiche Größe haben. Duarte erkennt dies an und empfiehlt, alles so lange zu zerkleinern, bis Items klein genug sind, um austauschbar zu sein. Das ist gute Praxis, aber es ist auch eine Form der Schätzung. Sie sagen implizit "das ist klein genug, um eine 1 zu sein", jedes Mal wenn Sie eine Story aufteilen. Sie haben nur die explizite Schätzung durch implizite Schätzung ersetzt. Teams, die an unterschiedlicher Arbeit arbeiten — in einer Woche Infrastruktur, in der nächsten Frontend-Features, danach Drittanbieter-Integrationen — können nicht so tun, als wären alle Stories gleich.

Neue Teams brauchen Kalibrierung

Ein Team, das seit zwei Jahren zusammen ist, kann Schätzungen oft überspringen, weil es gemeinsame mentale Modelle hat. Sie wissen ungefähr, was beim Erstellen eines neuen API-Endpunkts oder beim Redesign einer Seite involviert ist. Ein Team, das sich letzten Monat gebildet hat, hat das nicht. Story Points, und noch wichtiger die Diskussionen darum, bauen schnell gemeinsames Verständnis auf. Wenn ein Entwickler eine 3 schätzt und ein anderer eine 13, ist das folgende Gespräch der Moment, in dem das Team tatsächlich über die Arbeit lernt. Durchsatzdaten können Ihrem Team nicht beibringen, dass der Senior-Entwickler annahm, Sie würden die bestehende API verwenden, während der Junior-Entwickler annahm, Sie würden eine neue erstellen.

Stakeholder brauchen Prognosen

Product Manager, Vertriebsteams und Führungskräfte interessieren sich nicht für Story Points. Aber sie müssen wissen: "Wird Feature X vor der Konferenz im April ausgeliefert?" Durchsatzbasierte Prognosen können diese Frage beantworten. Ebenso Velocity-basierte Prognosen mit Story Points. Das #NoEstimates-Lager hat hier eine praktikable Alternative, aber sie erfordert historische Daten, die viele Teams nicht haben, besonders früh in einem Projekt oder nach bedeutenden Teamveränderungen.

Wann sich Story Points lohnen

Es gibt Situationen, in denen sich Schätzung bezahlt macht: Teams in der Anfangsphase. Die strukturierten Gespräche aus Planning Poker bauen schnell gemeinsames Verständnis auf. Die Schätzungen selbst sind weniger wichtig als die Meinungsverschiedenheiten, die sie aufdecken. Backlogs mit gemischter Komplexität. Wenn Ihr Backlog "ändere eine Button-Farbe" neben "migriere das Bezahlsystem" enthält, produziert das Zählen von Stories ohne sie zu bewerten Müll-Prognosen. Cross-Team-Koordination. Mehrere Teams, die in eine gemeinsame Roadmap einspeisen, brauchen eine gemeinsame Größen-Sprache, damit Product Manager Trade-off-Entscheidungen treffen können. Scope Creep erkennen. Stabile Velocity aber verpasste Commitments? Die Lücke zwischen geschätzten und tatsächlichen Punkten sagt Ihnen, dass Stories wachsen, nachdem sie in den Sprint eingetreten sind.

Wann man Story Points überspringen sollte

Story Points werden in anderen Kontexten zum Overhead: Reife Teams mit stabilem Durchsatz. Wenn Ihr Team seit 18+ Monaten zusammen ist und eine konsistente Anzahl ähnlich großer Stories pro Sprint fertigstellt, sagen Ihnen Durchsatzdaten bereits, was Sie wissen müssen. Kanban-artiger Fluss. Teams, die kontinuierlichen Fluss anstelle von Sprints verwenden, profitieren mehr vom Verfolgen der Zykluszeit (wie lange Items von Start bis Finish dauern) als von Vorab-Schätzung. Spikes und Forschungsaufgaben. Explorative Arbeit zu schätzen ist Raten über Raten. Setzen Sie stattdessen ein Zeitlimit: "Wir werden zwei Tage damit verbringen, dies zu untersuchen und berichten, was wir gefunden haben." Wartungs- und Support-Arbeit. Bugfixes und operative Aufgaben sind reaktiv. Durchsatz zu verfolgen macht mehr Sinn, als jedes Ticket einzeln zu schätzen.

Der Mittelweg, den die meisten Teams tatsächlich brauchen

Die nützliche Antwort ist nicht "immer schätzen" oder "nie schätzen". Es geht darum, Ihren Ansatz an Ihren Kontext anzupassen.

Kontext	Ansatz
Neues Team, komplexes Produkt	Planning Poker mit Story Points. Das Gespräch ist wichtiger als die Zahlen.
Etabliertes Team, unterschiedliche Arbeit	Leichtgewichtige Schätzung (T-Shirt-Größen oder schnelles Planning Poker). Halten Sie es schnell.
Etabliertes Team, einheitliche Arbeit	Verfolgen Sie den Durchsatz. Überspringen Sie die Schätzung.
Cross-Team-Roadmap-Planung	Verwenden Sie Story Points oder T-Shirt-Größen für High-Level-Prognosen.
Support/Wartung	Verfolgen Sie Zykluszeit und Durchsatz. Schätzen Sie keine einzelnen Tickets.

Die meisten Teams landen irgendwo in der Mitte: Sie schätzen die Stories, die es brauchen, und überspringen die Schätzung für Routine-Arbeit. Das ist in Ordnung. Das Ziel war nie, ein perfektes System zu haben. Das Ziel ist, gut genug Entscheidungen zu treffen über das, was gebaut wird und wann es fertig sein wird.

Was beide Seiten richtig machen

Die #NoEstimates-Bewegung erzwang eine nützliche Frage: "Erhalten wir Wert aus dieser Schätzsitzung, oder gehen wir nur durch die Bewegungen?" Jedes Team sollte dies regelmäßig fragen. Das Pro-Schätzungs-Lager hat recht, dass strukturierte Diskussion über anstehende Arbeit Überraschungen verhindert. Planning Poker funktioniert nicht, weil die Zahlen genau sind, sondern weil die Gespräche versteckte Komplexität aufdecken, bevor sie zu einem Problem mitten im Sprint wird. Der gewinnende Ansatz leiht sich von beiden: Schätzen Sie, wenn es nützliche Diskussion generiert oder die Prognosegenauigkeit verbessert. Hören Sie auf, wenn es zum Ritual wird. Wenn Ihr Team Planning Poker verwendet, unterstützt Kollabe schnelle Schätzsitzungen, die den Fokus auf Diskussion halten, nicht auf Zeremonie. Und wenn Sie stattdessen Durchsatz verfolgen, funktioniert das auch. Verwenden Sie, was Ihnen bessere Prognosen und weniger Überraschungen mitten im Sprint gibt.