Story Points vs. #NoEstimates: Unser Fazit

Keine der beiden Seiten gewinnt eindeutig. Schätzen Sie, um ein gemeinsames Verständnis zu schaffen und Meinungsverschiedenheiten aufzudecken; schätzen Sie nicht, um einen Termin vorherzusagen – leiten Sie diesen vielmehr aus dem Durchsatz ab. Wir betrachten Story-Points, #NoEstimates und den Erfinder, der sich von den Punkten distanziert hat, aus der Perspektive des „Steelman“, und treffen dann eine Entscheidung.

Keine der beiden Seiten gewinnt eindeutig. Führen Sie Schätzungen durch, um ein gemeinsames Verständnis zu schaffen und Meinungsverschiedenheiten aufzudecken; schätzen Sie nicht, um einen Termin vorherzusagen – erstellen Sie stattdessen eine Prognose auf der Grundlage des Durchsatzes. Die Zahl an sich ist nahezu wertlos. Das Gespräch, aus dem sie hervorgegangen ist, ist der eigentliche Gewinn.

Die Debatte wird als binäres Dilemma dargestellt – Punkte oder keine Punkte –, doch das ist sie nicht. Beide Lager haben in gewisser Hinsicht Recht, und hinter beiden steht eine maßgebliche Autorität. Die sinnvolle Position ist diejenige, die die stichhaltigsten Argumente beider Seiten aufgreift und nur jene Teile beibehält, die einem echten Sprint standhalten.

Argumente für Story-Punkte

Bei Mike Cohns Argumentation – der maßgeblichen Position der Befürworter des Punktesystems – ging es nie wirklich um die Zahl an sich. Vielmehr geht es darum, dass der Vorgang der relativen Schätzung ein Team dazu zwingt, die Komplexität zu erörtern, verborgene Annahmen aufzudecken und sich darauf zu einigen, was eine Story tatsächlich beinhaltet, bevor jemand Code schreibt. Punkte umgehen zudem eine bestimmte Problematik: Schätzt man in Tagen, wird über jede Zahl gefeilscht; schätzt man in einer abstrakten Einheit, hat das Feilschen keinen Anknüpfungspunkt mehr. Der Haken daran ist, dass jeder das Augenzwinkern mitbekommt – „Wir schätzen nicht die Zeit, sondern nur die Komplexität, damit wir den Sprint planen können, der zwei Wochen dauert“ – und die Abstraktion schützt das Team nur so lange, wie niemand sie direkt wieder in ein Datum umrechnet.

Steve McConnell liefert das fundierte Gegengewicht zu den Gegnern der Schätzung. Er vertritt die Ansicht, dass die Hauptursache für schlechte Schätzungen in der Regel ein Mangel an Schätzkompetenz ist, nicht das Schätzen an sich – und dass seriöse Schätzer drei Dinge voneinander trennen, die in der Debatte immer wieder miteinander vermischt werden: die Schätzung (was wahrscheinlich ist), das Ziel (was das Unternehmen will) und die Verpflichtung (was das Team verspricht). Wer diese drei Aspekte vermischt, dem erscheint die Schätzung natürlich als gescheitert. Hält man sie jedoch klar voneinander getrennt, leistet sie echte Arbeit.

Argumente für #NoEstimates

Nun zur anderen Seite, in voller Stärke. Allen Holubs Einwand lautet, dass Schätzungen stets ungenau sind – meist sogar extrem ungenau – und dass Story-Points dazu gedacht waren, die Dauer zu verschleiern, damit Manager den Zeitdruck verringern – doch die Teams rechnen sie direkt wieder in Stunden um und schaffen so genau jene Dysfunktionen, die durch die Einführung der Story-Points eigentlich verhindert werden sollten. Die Fibonacci-Skala nützt Ihnen nichts, wenn jeder insgeheim eine Umrechnungstabelle von Punkten in Stunden bei sich trägt.

Die pointierteste, datengestützte Behauptung stammt von Vasco Duarte: Bei realen Projekten lassen sich Prognosen durch das einfache Zählen der Stories ebenso gut erstellen wie durch die Summierung ihrer Story-Punkte. Wenn dies auf Ihre Arbeit zutrifft, sind die Punkte reine Formsache – Sie haben Rechenoperationen durchgeführt, um zu demselben Ergebnis zu gelangen, das Ihnen die Anzahl bereits geliefert hat. Messen Sie stattdessen den Durchsatz und die Zykluszeit; eine wachsende Warteschlange ist ein Frühindikator, den Sie im Voraus erkennen können, während die Velocity ein Spätindikator ist.

Und dann der schärfste Einwurf in der gesamten Debatte. Ron Jeffries, dem weithin die Erfindung der Story-Points zugeschrieben wird, ruderte 2019 zurück: „Ich habe die Story-Points vielleicht erfunden, und falls ja, tut es mir jetzt leid.“ Sein Problem besteht insbesondere darin, dass sie dazu verwendet werden, den Fertigstellungstermin von Arbeiten vorherzusagen und Teams miteinander zu vergleichen. Seine Alternative lautet nicht „Hören Sie auf zu planen“ – vielmehr geht es darum, Stories so klein zu schneiden, dass jeweils nur ein einziger Abnahmetest erforderlich ist, idealerweise weniger als ein Tag pro Story, sodass kaum noch etwas zu schätzen bleibt.

In welchen Fällen wir unsere Meinung ändern würden

Wir würden bei einem Team, dessen Arbeit bereits in kleine, einheitliche Einheiten unterteilt ist, vollständig auf #NoEstimates setzen. Sobald jede Story etwa einen Tag in Anspruch nimmt, das Zählen der Stories sowohl Prognosen als auch die Summierung von Punkten umfasst und das Schätzmeeting einen Mehraufwand darstellt, den man weglassen kann – das räumt McConnell ein und nennt dabei Arbeit in schnellen Zyklen, bei der die Aufgabe einfach darin besteht, „das Nächstnützliche zu tun“, als einen Kontext, in dem Schätzungen wenig beitragen.

Im gegenteiligen Fall – bei einer Organisation, in der Schätzungen tatsächlich niemals zu festen Verpflichtungen werden und niemand die Teams miteinander vergleicht – würden wir unsere Wachsamkeit gegenüber Punkten lockern. Dort besteht die Gefahr, vor der das Anti-Schätzungs-Lager warnt, nicht, und Punkte dienen lediglich als harmloser Gesprächsanstoß. Das Problem ist, dass eine solche Organisation selten ist. Die Instrumentalisierung ist die Regel, weshalb unser Urteil in diese Richtung tendiert.

Die praktische Umsetzung

one story 3 13 one dev another dev the gap is the point talk it out — don’t average A 3 beside a 13 means you’re picturing different work.
Das Ergebnis des Planning Poker ist nicht die Zahl, sondern die Differenz. Eine 3 neben einer 13 bedeutet, dass sich zwei Personen unterschiedliche Arbeitsumfänge vorstellen – schließen Sie diese Lücke durch ein Gespräch, anstatt den Mittelwert zu bilden.
  • Betrachten Sie Planning Poker als Mittel zur Erkennung von Meinungsverschiedenheiten und nicht als Vorhersageinstrument. Eine 2 und eine 13 für dieselbe Story sind das Signal – dies bedeutet, dass das Team kein gemeinsames Verständnis der Aufgabe hat. Diskutieren Sie so lange, bis die Streuung verschwindet; das Ergebnis ist die Einigung, nicht die endgültige Zahl.
  • Die Prognose basiert auf Durchsatz und Zykluszeit, nicht auf der Summe der Punkte. Velocity dient als Planungsgrundlage für das Team, stellt jedoch keinesfalls eine Zusage gegenüber Dritten dar.
  • Trennen Sie, wie Cohn sagt, die Schätzung von der Zusage. Eine Schätzung ist eine Vermutung; in dem Moment, in dem sie zu einem Versprechen wird, hat jemand ihre Bedeutung verändert, ohne das Team darüber zu informieren.
  • Wenn Sie Punkte verwenden, sollten Sie diese relativ halten. Sobald Sie diese in Stunden umrechnen, nehmen Sie eine verschleierte Zeitschätzung vor – mit dem gesamten Druck, der mit Zeitschätzungen einhergeht, und einer zusätzlichen Ebene der Verschleierung.
  • Teilen Sie die Story in kleinere Teile auf, anstatt sie zu dimensionieren. Jeffries hat Recht damit, dass der größte Teil des Wertes, um den in der Debatte gestritten wird, verschwindet, wenn die Stories so klein sind, dass die Schätzung kaum noch eine Rolle spielt.

Die Zahl ist bedeutungslos; entscheidend ist das Gespräch, aus dem sie hervorgegangen ist. Diese eine Zeile klärt den Großteil der Diskussion – und sorgt dafür, dass eine Planning-Poker-Sitzung wirklich nützlich bleibt, ohne vorzugeben, die Zukunft vorhersagen zu können.

Häufig gestellte Fragen

Sollten wir Story-Points oder #NoEstimates verwenden?

Verwenden Sie die Methode, die das Gespräch über die Schätzung in Gang bringt, und hören Sie auf, die Zahl als Vorhersage zu betrachten. Story-Punkte sind nützlich, um Meinungsverschiedenheiten aufzudecken – eine große Streuung bei einer Story bedeutet, dass das Team kein gemeinsames Verständnis davon hat. #NoEstimates ist die richtige Entscheidung, wenn Ihre Stories bereits klein und einheitlich aufgeteilt sind, denn dann dient das Zählen sowohl der Prognose als auch der Summierung der Punkte. In jedem Fall sollten Sie die Fertigstellung anhand des Durchsatzes prognostizieren und die Schätzung von der Festlegung trennen.

Hat der Erfinder der Story-Points diese wirklich abgelehnt?

Ron Jeffries, dem weithin die Prägung des Begriffs „Story Points“ zugeschrieben wird, schrieb im Jahr 2019: „Möglicherweise habe ich die Story Points erfunden, und falls dem so ist, tut es mir heute leid.“ Sein Einwand richtet sich gegen die Verwendung von Story-Points zur Vorhersage von Fertigstellungsterminen sowie zum Vergleich oder zur Bewertung von Teams. Die von ihm empfohlene Alternative lautet nicht „keine Planung“ – vielmehr geht es darum, Stories so klein zu unterteilen, dass jeweils nur ein einziger Abnahmetest erforderlich ist.

Wie lässt sich ein Release planen, ohne jede Story zu bewerten?

Messen Sie den Durchsatz – also die Anzahl der Stories, die das Team tatsächlich pro Woche abschließt – und berechnen Sie anhand dieser Rate den verbleibenden Rückstand. Vasco Duarte ist zu dem Ergebnis gekommen, dass das Zählen von Stories ebenso gut zur Prognose geeignet ist wie das Addieren von Story-Punkten; sobald die Stories also auf eine ähnliche Größe aufgeteilt sind, liefern die Punkte kaum zusätzliche Informationen, die die Anzahl nicht bereits bietet.

Weiterführende Literatur