Schätzen in der Produktentwicklung: So spart ihr viel Zeit mit der 3-Eimer-Schätzung

Freust du dich schon auf deine nächste Schätz-Session?

Ich höre oft „Bitte nicht schon wieder schätzen!”. Vielen Developern graust es beim Gedanken an die nächste Schätz-Runde. Mühsame Diskussionen um 5 oder 8 Story Points und nach einer Stunde sind vielleicht 7 User Stories geschätzt!

Es geht auch anders. In diesem Artikel stelle ich dir eine Alternative zu Planning Poker vor, die Schätzungen deutlich beschleunigt. Sie hat es einigen meiner Teams erheblich erleichtert zu Schätzungen zu kommen, die ihnen tatsächlich weitergeholfen haben.

Doch bevor wir loslegen, lohnt es sich kurz zu rekapitulieren, warum es überhaupt sinnvoll ist zu schätzen. 

Warum schätzen wir in der Produktentwicklung?

Viele Produkt-Teams schätzen einfach, weil es scheinbar dazugehört, ohne den Aufwand groß in Frage zu stellen oder sich Gedanken über den Mehrwert zu machen. Und das ist schade, denn: Schätzen ist keine wertstiftende Tätigkeit. Schätzen verursacht hauptsächlich Kosten. Wert entsteht dabei höchstens indirekt. Wie fördert also Schätzen die Wertschöpfung?

Die bekanntesten Möglichkeiten sind aus meiner Sicht:

1. Priorisieren
2. Prognostizieren
3. Verständnis entwickeln
4. Flow fördern

Schauen wir uns diese vier Punkte etwas genauer an.

1. Priorisierung auf Basis von Schätzungen

Die Idee: Sind zwei Items gleich wertvoll, aber unterschiedlich groß, kann die Product Ownerin das kleinere Item zuerst umsetzen lassen. Dies reduziert den Cost of Delay und schafft so mehr Wert.

Doch die Realität zeigt: Die wenigsten Product Owner verwenden Schätzungen für diese Art von Wert-Optimierung, also der Verringerung des Cost of Delay durch Priorisierung. Vielen ist das Konzept von Cost of Delay gar nicht bekannt. Ich würde empfehlen, Schätzungen zur Priorisierung nur dann durchzuführen, wenn der Product Owner sich einen signifikanten Nutzen davon verspricht.

2. Prognosen auf Basis von Schätzungen

Die Idee: Die Product Ownerin kann Prognosen über den zukünftigen Fortschritt machen, indem sie den bisherigen Fortschritt in Beziehung zur Größe der noch vor dem Team liegenden Aufgaben setzt. Dadurch sind unter gewissen Umständen Fragen beantwortbar wie „Was wird bis zur Messe fertig?” oder „Wie lange dauert es, bis wir diese Features präsentieren können?” So kann man z.B. Marketing-Aktivitäten auf die zu erwartenden Features abstimmen, um diese noch wertvoller zu machen.

Erwartungsmanagement durch Prognosen wird oft als ein Argument für Schätzungen angeführt. Tatsächlich ist das aber gar nicht so einfach. Das liegt an zwei Gründen.

Die Volatilität eines Product Backlogs

Erstens ist das Product Backlog in einem agil arbeitenden Team oft volatiler als vielen klar ist. Einmal habe ich ein Team begleitet, bei dem nach drei 2-Wochen-Sprints ⅔ der ursprünglich enthaltenen Product Backlogs Items durch andere ersetzt worden waren.

Trotzdem hatte die Product Ownerin die Vorstellung, sie müsse eine Velocity ermitteln, um so sagen zu können, an welchen Einträgen des Product Backlogs das Team in 6 Monaten arbeiten werde. Eine kurzer Überschlag ergab, dass bei gleichbleibender Volatilität nach dieser Zeit nur noch ca 1% der Items des Product Backlogs noch mit dem ursprünglichen Inhalt übereinstimmen werden. 

Die beste Prognose, die sich zu diesem Zeitpunkt also für die Zeit in 6 Monaten treffen ließ, lautet: „Wir werden wahnsinnig wichtige und wertvolle Dingen realisiert haben, von denen wir allerdings jetzt noch keine Ahnung haben.”

Zuverlässige Prognosen verlangen situationsbewussten Einsatz, methodisches Verständnis und eine geeignete Datengrundlage

Es kann schwieriger sein, als man zunächst vielleicht denkt, Schätzungen für zuverlässige Prognosen zu nutzen. Für eine tragfähige Aussage benötigt man eine solide Datengrundlage vergangener Sprints, ein geeignetes Tool, aber auch ein gutes Verständnis davon, wie wahrscheinlich in der gegebenen Situation unvorhersehbare Ereignisse sind.
Einfache Tools basieren oft auf einem rollenden/gleitenden Durchschnitt der bisherigen Umsetzungsgeschwindigkeit. Für stabile Arbeitssituationen können sie hilfreich sein, um zu Prognosen in der näheren Zukunft zu gelangen – oder auch um zu verdeutlichen, dass das Planungsrisiko zunimmt, je weiter man in die Zukunft geht. (Ein solches Tool ist beispielsweise der Team-Forecaster, der als Excel-Template von meinen Kollegen aufbereitet und mit einer Anleitung hier kostenlos angefordert werden kann.)

Für aussagekräftige Prognosen wird man jedoch meist um eine Monte-Carlo-Simulation nicht herumkommen.

Wer hier Kenntnisse hat und sicher in der methodischen Einordnung ist, wird damit gut und gerne arbeiten. Nach meiner Erfahrung werden aber in der Praxis die vom Team ermittelten Schätzwerte für solche Prognosen eher selten verwendet. Falls du das anders erlebst oder vielleicht mehr zu Monte-Carlo- oder durchschnitts-basierten Prognosen wissen willst, hinterlasse gerne einen Kommentar zu diesem Artikel.

3. Schätzungen als ein (Um-)Weg zu mehr Verständnis

Kommen wir nun zur dritten Möglichkeit, wie durch Schätzen die Wertschöpfung indirekt gefördert werden kann: das Schaffen von gemeinsamem Verständnis. 

Es ist unabdingbar für Teams, dass Developer und Product Owner vor der Umsetzung ein gemeinsames Verständnis davon haben, was zu realisieren ist. Ein Schätztermin ermöglicht es, in einem gemeinsamen Gespräch Rückfragen zu stellen und Klarheit über Inhalt und Umfang zu schaffen.

Ich bin jedoch kein so großer Freund davon, Schätzungen zum Schaffen von Verständnis zu nutzen. Warum?

Zunächst ist es recht umständlich, den Umweg über die Erzeugung einer Schätzung zu gehen, nur um mehr Verständnis zu schaffen. Es gibt andere Techniken wie Quick Design Sessions oder Example Mapping, die meiner Erfahrung nach direkter Klarheit über den Inhalt einer User Story schaffen.

Außerdem führt die Gleichsetzung von „Ich habe verstanden, was vorab zu verstehen ist” mit „Ich weiß, was alles zu tun ist” tendenziell dazu, dass Teams in Situationen von größerer Unsicherheit sich nicht trauen, einfach etwas zu probieren, um zu lernen, sondern stattdessen leicht in einer Analyse-Paralyse stecken bleiben.

4. Flow fördern durch Aussieben zu großer Items

Der letzte Vorteil, den Schätzungen mit sich bringen, ist das Fördern von Flow. Was ist das? Ein Kollege sagt „Flow ist, wenn Wert geschmeidig zum Kunden fließen kann.”

Eine wichtige Voraussetzung dafür ist die Arbeit an Dingen ähnlicher Größe. Stell dir vor, ihr schippt Kies in eine Schubkarre. Plötzlich liegt ein Felsbrocken zwischen den Kieselsteinen. Ihr müsst die Schaufeln weglegen, die Trageriemen holen und den Brocken gemeinsam in die Schubkarre wuchten. Der Flow ist gestört.

Wenn man Schätzungen nutzen kann, um die Dinge, an denen man arbeitet, in etwa ähnlich große Einheiten einzuteilen, wäre das also sehr hilfreich.
Und genau das tun wir in Scrum, indem wir fragen: Sind wir zuversichtlich, dieses Item (oder besser: einige solcher Items) in einem Sprint erledigen zu können?

Was passiert also, wenn wir uns beim Schätzen auf die Beantwortung der besonders relevanten Frage „Passt das Item in den Sprint?” fokussieren? Die meisten Teams sind in der Lage, diese Frage extrem schnell zu beantworten. Wir bekommen deshalb über diese Frage eine extrem schnelle Schätzmethode, die dem Team gleichzeitig von praktischem Nutzen ist.
Im Folgenden zeige ich anhand der 3-Eimer-Schätzung, wie das aussehen kann.

Die 3-Eimer-Schätzung

Schauen wir uns zunächst an, wie die Methode funktioniert. Im Anschluss teile ich ein paar interessante Erfahrungen damit aus der Praxis. Beginnen wir mit der grundsätzlichen Vorgehensweise.

Ihr braucht drei „Eimer” (Stapel, Spalten, Plätze, Bereiche), die beschriftet sind mit:

1. Passt so! (Just Right)
2. Zu groß! (Too Big)
3. ??

Nun ordnet ihr die zu schätzenden Product Backlog Items einem der beiden linken Eimern zu.

In den „Passt so“-Eimer kommen alle Items, die so groß (oder klein) sind, dass ihr problemlos mehrere davon in einem Sprint erledigen könnt. Mit „erledigen” ist gemeint: Umsetzen, sodass sie fertig sind im Sinne der Definition-of-Done.

In den „Zu groß“-Eimer kommen alle Items, die größer sind, von denen also die Developer nicht das Gefühl haben, dass sie problemlos mehrere davon in einem Sprint erledigen können. Gelegentlich werdet ihr dabei über ein Item stolpern, zu dem ihr noch zu wenig wisst, als dass ihr es in einen der beiden ersten Eimer werfen könnt. Dieses Item kommt dann in den „??“-Eimer.
Typischerweise passiert das eher selten, denn hier landen nicht alle Items, bei denen noch eine Frage offen ist, sondern nur solche, bei denen offene Fragen verhindern, dass ihr es einem der beiden anderen Eimer zuordnen könnt.

Wichtig dabei: Dieses Zuordnen geschieht sehr schnell und ohne, dass groß über Inhalte geredet wird. Uneinigkeit liegt in der Regel an fehlender Klarheit. Für diese Fälle: Ab damit in den ??-Eimer.

Anschließend nehmt ihr euch die Items im ??-Eimer vor und versucht schnell und leichtgewichtig die Fragen zu klären, die euch davon abhalten, das Item einem der beiden anderen Eimer zuzuordnen. Setzt euch eine enge Timebox, z.B. 2 bis maximal 5 Minuten. Wenn ihr die Frage nicht innerhalb dieser Zeit klären könnt, kommt das Item in den „Zu groß!“-Eimer.

Items im „Zu groß“-Eimer werden dann in anschließenden Product Backlog Refinement-Sessions in kleinere Items heruntergebrochen. Für User Stories kann man hier die ganz üblichen User Story Splitting-Techniken verwenden.

Gelegentlich passiert es, dass sehr viele Items in ?? landen. Woran liegt das?

Es könnte sein, dass dem Team einfach Erfahrung in der gemeinsamen Arbeit fehlt. Dann hilft gemeinsames Raten, Ausprobieren und nach einem Sprint nochmal „eimern”. Entweder merkt man dann, dass man dem eigenen Gefühl doch mehr trauen darf als gedacht, oder man erkennt, dass man im letzten Sprint viel gelernt hat.

Manchmal landen auch viele Items in ??, weil psychologische Sicherheit im Team fehlt. Die Developer trauen sich nicht, ihre Einschätzung sichtbar zu machen. Dann ist die 3-Eimer-Schätzung ein sehr schneller Weg, diese wertvolle Einsicht zu gewinnen. Denn dann wird das Team nicht nur Probleme mit dem Schätzen haben, sondern auch mit dem Liefern von guten Ergebnissen. In so einem Fall darf man an anderen Stellen ansetzen als an der Schätzmethode.

Der Charme der 3-Eimer-Schätzung

Mir gefällt, dass „Eimer-Schätzung” bereits irgendwie einfach klingt. Und ich mag es, dass Teams manchmal lieber „eimern” anstatt „schätzen” sagen.

Ein Kollege bezeichnete das Vorgehen mal als „Right-Sizing”. Das wiederum kenne ich als Euphemismus für Down-Sizing, also den Abbau von Überkapazitäten in der Produktion, typischerweise verbunden mit Entlassungen oder anderen unschönen Assoziationen, sodass ich auf diesen Begriff lieber verzichte.
Wenn du einen anderen Namen (gerne mit Quelle) kennst, würde ich mich sehr freuen, wenn du ihn unten in den Kommentaren hinterlässt.

Hilfreiche Varianten der 3-Eimer-Schätzung

Den oben beschriebenen Ablauf kann man je nach Situation variieren, indem man die verwendeten Materialien oder den Ablauf abändert.

Verwendete Materialien

Ihr könnt unterschiedliche Materialien für die Items verwenden. Wenn ihr physisch in einem Raum seid, empfehle ich Karteikarten auf einem Tisch. Karten lassen sich leichtgewichtig hin- und herschieben und stapeln, ohne dass sie verkleben.

Auch online könnt ihr „eimern”. Am einfachsten geht es mit Miro oder einem anderen kollaborativen White-Board-Tool, bei dem alle Teilnehmer:innen gleichberechtigt virtuelle Karten verschieben können.

Ablauf

Sequenziell: Jemand liest eine Karte vor und das Team sagt zeitgleich: „Passt!“, „Zu groß“ oder „Häh?“ (oder irgendetwas anderes, das zu eurer Team-Kultur passt). Die Wörter sind so verschieden, dass man sofort hört, wenn keine einheitliche Meinung herrscht. Dann kommt das Item in den „??“-Eimer. Diese Variante ist etwas langsamer als die parallele Variante, kann aber dafür auch verwendet werden, wenn die Items nicht auf Karten sondern nur auf einer Liste vorliegen

Parallel: Alle zuzuordnenden Karten liegen auf dem (virtuellen) Tisch. Daneben gibt es die drei Überschriften, die die Eimer symbolisieren. Dann dürfen alle GLEICHZEITIG beliebig Karten auf oder zwischen den Stapeln verschieben. Karten, die mehr als zweimal wandern, landen im „??“-Eimer.

Gemischt: Manche Teams starten gerne sequenziell und wechseln dann zu parallel.

Eine Geschichte aus der Praxis

Eine sehr eindrückliche Erfahrung mit der 3-Eimer-Schätzung hatte ein Team, das ich bei einem großen Versicherungskonzern begleitet habe. Sie hatten vorher noch nicht zusammengearbeitet und waren völlig ratlos, wie sie denn schätzen sollten.

Wir beschlossen, zunächst einfach ohne Story-Point-Schätzungen zu starten, um erst etwas fertig zu bekommen und dann zum Thema Schätzung zurückzukehren. Um zu klären, was man in einen Sprint nehmen könnte, zeigte ich ihnen die 3-Eimer-Schätzung. Sie waren begeistert, denn nach nur einer halben Stunde war das Thema „Schätzen” vom Tisch. Und gelacht werden durfte auch dabei.

Als das Team nach dem ersten Sprint für alle unerwartet tatsächlich etwas liefern konnte, war das Interesse einer ganzen Reihe von Stakeholdern geweckt und die Product Ownerin war zunächst vollauf beschäftigt. Niemand im Team hatte Zeit, sich dem Thema „Präzisere Schätzungen“ zu widmen, wir sammelten einfach weiter Erfahrung mit unseren 3 Eimern und mit der gemeinsamen Arbeit am Produkt.

Zwei Sprints später kam das Thema Schätzungen wieder auf. Die Stakeholder wollten wissen, wann sie „ihre” Features kriegen. Das Product Backlog hatte inzwischen mehr als 60 Einträge und die Developer wenig Lust, etwas Aufwändigeres zu tun als zu eimern. Spannend fanden alle die Beobachtung, dass wir im ersten Sprint 5, und in Sprint 2 und 3 jeweils 7 „Passt so”-Items erledigt hatten. 

Die Product Ownerin kam zu dem Schluss: „7 Stories pro Sprint. Ich glaube, damit kann ich rechnen.” Und mit diesem Vorgehen war sie erfolgreich für den gesamten Rest der Zeit.

Ein weiterer spannender Punkt: Später stellten wir fest, dass 90% der „Zu groß!“-Items in 3-8 „Passt so“ -Items zerlegt werden konnten. Das erzeugt zwar eine recht große Streuung, half uns dennoch dabei zu entscheiden, was man sich überhaupt noch näher anschauen sollte angesichts der Tatsache, dass unser Budget noch für 5 weitere Sprints ausreichte.

So stellten wir verblüfft fest, dass uns die 3-Eimer-Schätzung trotz ihrer Einfachheit nicht nur beim Flow half, sondern auch bei der Prognostizierung und sogar beim Schaffen von Verständnis.

Mein Fazit zu den Vorzügen der 3-Eimer-Schätzung

Die 3-Eimer-Schätzung ist eine extrem schnelle, einfache Schätzmethode, die unmittelbar die Bedürfnisse der Entwickler abdeckt. Product Owner können sie außerdem zur Erstellung von Prognosen und mit gewissen Einschränkungen auch zur Priorisierung nutzen. Den größten Vorteil hat die Methode nach meiner Erfahrung beim Fördern von Arbeitsfluss.
Grundsätzlich ist es wichtig, sich klar zu machen, dass der Schätzvorgang an sich keinen direkten Wert liefert. Wir sollten also immer abwägen, ob die verwendete Zeit, die wir in das Schätzen investieren, durch den indirekten Wert der Schätzung gerechtfertigt wird.
Die 3-Eimer-Schätzung eignet sich daher durch ihre unkomplizierte und schnelle Umsetzung ideal dazu, Erfahrung mit indirekter Wertschöpfung durch Schätzung zu sammeln.  

Mich interessiert an dieser Stelle brennend, welche Schätzmethoden ihr derzeit einsetzt, ob ihr die 3-Eimer-Schätzung bereits kennt oder sogar regelmäßig nutzt und welche Erfahrungen ihr damit gesammelt habt. Ich freue mich über Kommentare zu diesem Beitrag oder über eine persönliche Nachricht.

(überarbeitete Version, erstveröffentlicht am 25. Mai 2022)

Für alle, die mit Scrum effektiv Produkte entwickeln wollen.

Die Grundlagen-Trainings der Scrum Alliance für Product Owner und Developer mit Pascal Gugenberger:

PO-Track: Certified Scrum Product Owner^® (CSPO) und Advanced Certified Scrum Product Owner^® (A-CSPO)

Developer-Track: Certified Scrum Developer^® (CSD) und Advanced Certified Scrum^® (A-CSD)