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, sondern leiten Sie Prognosen stattdessen aus dem Durchsatz ab. Wir betrachten Story-Punkte, #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. Schätzen Sie, um ein gemeinsames Verständnis zu schaffen und Meinungsverschiedenheiten aufzudecken; schätzen Sie nicht, um einen Termin vorherzusagen, sondern leiten Sie Prognosen stattdessen aus dem Durchsatz ab. Die Zahl an sich ist nahezu wertlos. Das Gespräch, aus dem sie hervorgegangen ist, stellt den eigentlichen Wert dar.

Die Debatte wird als binäre Frage dargestellt – Punkte oder keine Punkte –, doch das trifft nicht zu. Beide Lager haben in gewisser Hinsicht Recht, und hinter beiden steht eine maßgebliche Autorität. Die sinnvolle Position ist jene, die die stichhaltigsten Argumente beider Seiten aufgreift und nur die Teile beibehält, die einer praktischen Überprüfung standhalten.

Argumente für Story-Punkte

Bei Mike Cohns Argumentation – der maßgeblichen Position der Befürworter – ging es nie wirklich um die Zahl. 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 ein bestimmtes Problem: Schätzt man in Tagen, wird über jede Zahl gefeilscht; schätzt man in einer abstrakten Einheit, fehlt dem Feilschen jeglicher Anknüpfungspunkt. Der Haken daran ist, dass jeder den Wink versteht („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 zur Fraktion der Schätzungsgegner. 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 wünscht) und die Zusage (was das Team verspricht). Wer diese drei Aspekte vermischt, dem erscheint die Schätzung natürlich als unbrauchbar. 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-Punkte dazu gedacht waren, die Dauer zu verschleiern, damit Manager den Zeitdruck aufheben würden; dennoch rechnen die Teams sie direkt wieder in Stunden um und schaffen so genau jene Dysfunktionen neu, die durch die Einführung der Story-Punkte eigentlich verhindert werden sollten. Die Fibonacci-Skala nützt Ihnen nichts, wenn jeder insgeheim eine Umrechnungstabelle von Punkten in Stunden parat hat.

Die pointierteste, datengestützte Aussage stammt von Vasco Duarte: Bei realen Projekten lassen sich Prognosen durch das einfache Zählen von Stories ebenso gut erstellen wie durch die Addition 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 Zählung 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, dementierte diese im Jahr 2019: „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 einen 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 der Prognosen als auch der Gesamtpunktzahl erfolgt und das Schätzmeeting als unnötigen Aufwand angesehen werden kann, können Sie darauf verzichten. McConnell räumt dies ein und nennt schnelllebige Arbeitsabläufe, bei denen die Aufgabe einfach darin besteht, „das Nächstnützliche zu tun“, als einen Kontext, in dem Schätzungen wenig beitragen.

Im umgekehrten Fall würden wir unsere Wachsamkeit gegenüber Punkten lockern: in einer Organisation, in der Schätzungen tatsächlich niemals zu verbindlichen Verpflichtungen werden und niemand die Teams miteinander vergleicht. Dort besteht die Gefahr, vor der das Lager der Schätzungsgegner warnt, nicht, und Punkte sind lediglich ein harmloser Gesprächsanlass. 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 Diskrepanz. Eine 3 neben einer 13 bedeutet, dass sich zwei Personen unterschiedliche Arbeitsinhalte vorstellen; schließen Sie diese Lücke daher 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 Verpflichtung. 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, verbunden mit dem gesamten Druck, der mit Stunden-Schätzungen einhergeht, und einer zusätzlichen Ebene der Verschleierung.
  • Teilen Sie die Story in Abschnitte auf, anstatt sie zu dimensionieren. Jeffries hat Recht damit, dass der Groß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 sie sorgt dafür, dass eine Planning-Poker-Sitzung wirklich nützlich bleibt, ohne so zu tun, als könne sie die Zukunft vorhersagen.

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 in kleine, einheitliche Einheiten unterteilt sind, denn dann dient das Zählen dieser Einheiten 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 deren Verwendung zur Vorhersage von Fertigstellungsterminen sowie zum Vergleich oder zur Bewertung von Teams. Die von ihm empfohlene Alternative ist nicht „keine Planung“. Vielmehr geht es darum, Stories so klein zu gliedern, dass jeweils nur ein einziger Abnahmetest erforderlich ist.

Wie lässt sich eine Veröffentlichung planen, ohne jede einzelne Story zu bewerten?

Messen Sie den Durchsatz, also die Anzahl der Stories, die das Team tatsächlich pro Woche abschließt, und projizieren Sie den verbleibenden Backlog auf der Grundlage dieser Rate. Vasco Duarte ist zu dem Ergebnis gekommen, dass das Zählen von Stories für Prognosen etwa genauso gut geeignet ist wie das Addieren von Story-Punkten; sobald die Stories also in ähnlich große Einheiten unterteilt sind, liefern die Punkte kaum zusätzliche Informationen, die die Anzahl nicht bereits bietet.

Weiterführende Literatur