10 x schneller als Planning Poker! Unglaublich viel Zeit sparen mit der 3-Eimer-Schätzung

Du freust dich schon auf deine nächste Schätz-Session?

Ich höre oft “Bitte nicht schon wieder schätzen!” Vielen Developer 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 meine schnellste Alternative zu Planning Poker vor. Sie hat es einigen meiner Teams erheblich leichter gemacht, zu Schätzungen zu kommen, die ihnen tatsächlich weitergeholfen haben.

Doch bevor wir loslegen, lohnt es sich, kurz zu rekapitulieren, warum wir eigentlich schätzen. Denn diese Vorteile wollen wir ja erhalten, auch wenn wir weniger Zeit für die Schätzung aufwenden.

Warum schätzen wir eigentlich?

Viele Teams schätzen einfach, weil man das halt tut, ohne es groß in Frage zu stellen. Und das ist schade, denn Schätzen ist ja keine wertstiftende Tätigkeit. Schätzen verursacht hauptsächlich Kosten. Wert entsteht höchstens indirekt. Wie fördert also Schätzen die Schaffung von Wert?

Die wichtigsten Möglichkeiten sind aus meiner Sicht:

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

Schauen wir sie uns etwas genauer an.

Priorisieren erfolgt selten 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.

Leider verwenden die wenigsten Product Owner Schätzungen für diese Art von Wert-Optimierung. Vielen ist sogar das Konzept von Cost of Delay gar nicht bekannt. Ich würde empfehlen, Schätzungen nicht mit diesem Ziel zu erzeugen, es sei denn, der Product Owner möchte sie explizit dafür verwenden und verspricht sich einen signifikanten Nutzen davon.

Prognosen auf Grund von Schätzungen sind schwierig

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 kriegen wir bis zur Messe?” oder “Wie lange dauert es, bis wir diese Features haben?” 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 Argument für Schätzungen angeführt. Tatsächlich ist das gar nicht so einfach, und zwar aus zwei Gründen.

Erstens ist das Product Backlog in einem agil arbeitenden Team oft volatiler als vielen klar ist. Einmal habe ich ein Team begleitet, bei dem sich nach 3 2-Wochen-Sprints ⅔ der ursprünglich enthaltenen Product Backlogs Items entfallen und durch andere ersetzt worden waren. Trotzdem hatte die Product Ownerin die Vorstellung, sie müsse eine Velocity ermitteln um so sagen zu können, ob an welchen Dingen im Product Backlog sie in 6 Monaten arbeiten werden. Eine kurzer Überschlag ergab, dass bei gleichbleibender Volatilität nach dieser Zeit nur noch ca 1% der Items des Product Backlog Items noch mit dem ursprünglichen Inhalt übereinstimmt. Die beste Prognose, die sie darüber abgeben kann, ist also: “Wir werden wahnsinnig wichtige und wertvolle Dingen realisiert haben, von denen wir allerdings jetzt noch keine Ahnung haben.”

Zweitens ist es etwas schwieriger als man zunächst vielleicht denkt, die Schätzungen für zuverlässige Prognosen zu nutzen. Zunächst ermittelt man dafür die Velocity (Zahl der fertigen, ggf. nach Größe gewichteten Items je Sprint). Anhand der gemessenen Velocity-Werten für vergangene Sprints kann man nun prognostizieren, was passiert, wenn sich nichts grundlegend ändert. Allerdings kommt man für halbwegs tragfähige Aussagen eigentlich um eine Monte-Carlo-Simulation nicht herum (was wiederum einfacher ist als man zunächst vielleicht denkt).

In der Praxis werden die vom Team ermittelten Schätzwerte für solche Prognosen in meiner Erfahrung eher selten verwendet. Falls du das anders erlebst oder vielleicht mehr zu Monte-Carlo-basierten Prognosen wissen willst, hinterlasse gerne einen Kommentar zu diesem Artikel.

Schätzungen sind ein Umweg zu mehr Verständnis

Kommen wir zur Schaffung von gemeinsamem Verständnis. Es ist unabdingbar für Teams, dass Developer und Product Owner vor der Umsetzung ein gemeinsames Verständnis davon schaffen, 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.

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

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 statt dessen leicht in einer Analyse-Paralyse stecken bleiben.

Flow fördern durch Aussieben zu großer Items ist hilfreich

Der letzte Aspekt 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, und 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, so etwa ähnlich groß zu machen, wäre das also sehr hilfreich. Und das tun wir in Scrum, in dem 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 es in den Sprint?“ fokussieren? Zum Glück können die meisten Teams diese Frage extrem schnell beantworten. Wir bekommen deshalb eine extrem schnelle Schätzmethode, die dem Team gleichzeitig praktisch hilft.

Die 3-Eimer-Schätzung

Ich zeige dir zunächst, wie die Methode funktioniert und dann teile ich ein paar interessante Erfahrungen damit aus der Praxis. Beginnen wir mit der grundsätzlichen Vorgehensweise.

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

• Passt so! (Just Right)
• Zu groß! (Too Big)
• ??

Nun ordnet ihr die zu schätzenden Product Backlog Items einem der linken beiden Eimer 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, so dass 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 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, bei 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.

Dieses Zuordnen geschieht sehr schnell und ohne, dass groß über Inhalte geredet wird. Uneinigkeit liegt in der Regel an fehlender Klarheit. 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 min. 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.

Warum bitte “3-Eimer-Schätzung”?

Ganz einfach. Ich nenne diese Methode “3-Eimer-Schätzung”, weil ich keinen anderen Namen dafür kenne. Und die drei Eimer sind schon ein markantes Element der Methode. Zudem klingt Eimer irgendwie einfach. Und vielleicht gefällt mir, dass manchmal Teams dann lieber “eimern” statt “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. Nicht schön.

Also bleibe ich erstmal bei “3-Eimer-Schätzung”.

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

Den oben beschriebenen Ablauf kann man je nach Situation variieren. Die häufigsten Varianten sind:

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 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 wass 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

Als Beispiel möchte ich hier ein Team nennen, 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, 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. Für Schätzungen war keine Zeit, 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 denn “ihre” Features kriegen. Das Product Backlog hatte inzwischen mehr als 60 Einträge, und die Entwickler 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-schon” (die Versicherung ist in Süddeutschland) Items erledigt hatten. Die Product Ownerin sagte: “7 Stories pro Sprint. Ich glaube, damit kann ich rechnen” Und das tat sie, für den gesamten Rest der Zeit.

Später stellten wir übrigens fest, dass 90% der „Zu groß!“-Items in 3-8 „Passt schon“-Items zerlegt werden konnten. Das war zwar eine recht große Streuung, half uns dennoch zu entscheiden, was man sich überhaupt noch näher anschauen sollte angesichts der Tatsache, dass wir dann noch Budget für 5 Sprints hatten.

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

Fazit

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.

Mich würde brennend interessieren, welche Schätzmethoden ihr derzeit einsetzt, ob ihr diese Methode auch kennt oder sogar in der Praxis einsetzt und welche Erfahrungen ihr damit gesammelt habt. Bitte einfach hier unten kommentieren.