Im ersten Artikel der Blogreihe „Wovon der Scrum Guide NICHTS sagt” hat unser Kollege Andreas erklärt, warum die „Definition of Ready” in der aktuellsten Version von Scrum Guide nicht mehr erwähnt wird. Interessanterweise, das gleiche gilt auch für die Begriffe „Schätzung”, „Estimation” und „Story Points”. Weshalb aber?

Analog dazu werden Schätzmethoden wie Story Points oder Scrum Poker ebenfalls nicht (mehr) erwähnt. Zwar werden Burn-Up- und -Down-Charts, sowie Cumulative-Flow-Diagramme genannt, um Fortschritt vorherzusagen, aber nicht, wie diese zu befüllen sind. Eine Prüfungsfrage von Scrum.org zielt darauf ab, welche Schätzeinheit vom Dev-Team einzusetzen ist, um ausgewählte Produktbacklog-Einträge in ein funktionierendes Inkrement umzuwandeln. Die Antwort darauf ist ebenfalls sehr unkonkret, nämlich „jegliche nützliche Techniken zur Größenbestimmung / was auch immer dem Team hilft”.

Aber warum sagt der Scrum Guide hierzu denn eigentlich nichts konkretes?

Der Scrum Guide in seiner aktuellen Version möchte weniger Vorgaben enthalten und dem Scrum Team mehr Freiheiten gewähren, sich selbst zu managen. Er überlässt es dem Scrum Team, mittels welcher Hilfsmittel es sich bedient, um Wert zu liefern und das Sprint- sowie Produktziel zu erreichen.

Während des Sprint-Planning-Events (Thema zwei) steht im Scrum Guide lediglich, dass:

• die selektierten Produkt-Backlog-Einträge (ggf.) verfeinert werden können (vgl. „Klärung”)
• das Entwicklungsteam auf Basis ihren bisherigen Leistung, ihrer zukünftigen Kapazität und ihrer Definition of Done (DoD)

„in etwa vorhersagen können”, was in diesem Sprint abgeschlossen werden kann. Dies kommt der Definition einer Schätzung schon sehr nahe.

Exkurs: Arbeit wird als komplex und emergent verstanden. Die Teammitglieder sollen sich auf ein erreichbares Sprint-Ziel einigen und darauf verpflichten, nicht aber auf eine etwaige Arbeitsprognose. So die Auffassung des Scrum Guides.

Ein wenig Archäologie:

Funfact: ihren Ursprung haben Aufgabenbeschreibungen in Form von User-Stories und Epics gar nicht in Scrum (also von Ken Schwaber and Jeff Sutherland), sondern im „Extreme Programming” (XP). Kent Beck setzte dieses Konzept erstmals 1996 (also ca. 1 J. nach dem „Release” von Scrum auf der OOPSLA 1995) in Form von „Story Cards” in einem Projekt bei Chrysler ein. Mit an Bord im damaligen Chrysler-Projekt waren auch Ron Jeffries und Ward Cunningham, sowie Schätzungen in Form von „Story Point”-Einheiten. In diesem Projekt wurden die Einheiten noch in „idealen Entwicklertagen” (ET) angegeben und dann schlichtweg als Story Points (SP) umgerechnet, sprich 1 ET = 1 SP.

Kent Beck veröffentlichte daraufhin im Jahr 2000 die Erstausgabe von „Extreme Programming Explained. Embrace Change” (ISBN 0-201-61641-6), worin er das Methoden-Rahmenwerk bzw. Vorgehensmodell erläutert.

Ok, welche Meinung & Strömungen gibt es hierzu in der Scrum-Community, bzw. welche Best Practices am Markt?

Um Boris Gloger zu zitieren: „… lasst es am Besten ganz sein – würde ich jetzt am Liebsten sagen. Aber das hilft euch ja nicht, manchmal müsst ihr in eueren Projekten eben doch schätzen.”

Ebenso wie User Stories haben sich Schätzungen in Story Points in der Zwischenzeit in der agilen Praxis etabliert. Den Hauptanwendungsfall stellen sie zur Berechnung der Sprint-Velocity dar, mittels derer, bspw. in Kombination mit einem Burn-Down-Chart, sich eine „Wahrscheinlichkeitsrechnung” durchführen lässt, wann das Backlog abgearbeitet sein könnte bzw. die Software einen vorher definierten Funktionsumfang hat. Besondere Relevanz erhält dies im Zusammenhang mit den von Stakeholdern oft gestellten Fragen nach dem „Fertigstellungstermin” und den Kosten.

Das Verständnis und die Nutzung von Story Points hat sich im Vergleich zum Chrysler-Projekt von 1996 inzwischen dahingehend nachgeschärft, dass Story Points als Maßzahl / Einheit / Hilfsmittel zur relativen Aufwandsabschätzung verwendet werden. Relatives Schätzen bedeutet hierbei, dass wir vor unserem geistigen Auge zwei Dinge in ihre relative Größe zueinander setzen, d. h. sie miteinander vergleichen und abwägen. Wichtig ist in diesem Zusammenhang ein „Anker”, d. h. eine Referenzstory, womit alle anderen zu schätzenden Stories verglichen werden. Als eine mögliche Maßeinheit haben sich hierbei in der agilen Praxis wiederum Story Points bewährt, und zwar in der „unechten” Fibonacci-Folge (1-2-3-5-8-13-20-40-100). Story Points stellen hierbei Komplexität dar. Komplexität wiederum kann aus vielen Faktoren bestehen, bspw. Risiko, Unsicherheit, Aufwand oder erforderlichem Wissensaufbau. Je höher die Punktzahl, desto komplexer die Aufgabe.

Beim relativen Schätzen werden Tickets / Tasks / Epics eines einzelnen Software-Projektes eines einzelnen Teams miteinander verglichen. Der Vergleich mit Tickets aus anderen Projekten und anderen Teams ist in diesem Fall nicht sinnvoll, da jedes Projekt anders und unterschiedlich ist, ebenso wie jedes Team und jeder Mensch.

Lesetipp: erwähnen möchten wir in diesem Zusammenhang noch das Buch „Agile Estimating and Planning“ von Mike Cohn (Erstausgabe 11/2005, ISBN 976-0-13-147941-8.)

Zu den beiden häufigsten Schätzmethoden lässt sich ergänzen:

Weitere Schätzmethoden:

• T-Shirt-Größen (z. B. XXS bis XXXL)
• Tiere (z. B. Ameise, Maus, Frosch, Katze, Hund, Löwe, Kuh, Elefant, Giraffe, Wal, etc. pp.)
• Function points (für Komplexitätsschätzung)

„Trends in estimating”

Da sich das „ausreichend gute” Besprechen mit anschließendem Schätzen aller User Stories – in Abhängigkeit ihrer Anzahl – als sehr zeitintensiv herauskristallisiert hat, sind im Daily Business inzwischen viele Teams zum „no estimations”-Ansatz übergegangen. D. h. es wird „eigentlich” nicht mehr geschätzt. Selektierte Product Backlog Items (PBI) werden pro forma mit Story Point-ähnlichen Zahlen versehen – bspw. 1 bis 4, wobei 1 = klein, 2 = mittel, 3 = groß, 4 = zu groß. Der Austausch und die Kommunikation im Team sind nach wie vor wichtig, um ein gemeinsames Verständnis des PBI´s zu entwickeln. Andere Methoden wie bspw. Velocity-Tracking oder dem Befüllen eines Burndown-Charts verlieren dagegen an Bedeutung.

Fazit

Wie im vorherigen Artikel dieser Serie „Definition of Ready” bereits angesprochen, gibt es auch für Schätzungen kein „one size fits all”. Die Anwendung von Schätzmethoden, sowie deren konkrete Art hängt unserer Erfahrungen nach von mehreren Faktoren ab. Erwähnt sei in diesem Zusammenhang bspw. das Umfeld (Art der Organisation / Unternehmen), sowie der Reife des Teams, oder die Dauer der Zusammenarbeit.

… and now it’s up to you!

Setzt ihr Schätzmethoden ein? Wenn ja, welche bzw. welche kennt ihr noch?

Wann genau (zu welchem Event, Quality Gate, etc.) schätzt ihr?

Welche Erfahrungen habt ihr mit eueren Schätzungen gemacht?

Schreibt uns eine Nachricht: hello@qualityminds.de