Magic Estimation Übung – oder was kann mein Toaster?
Seit April ist ein neues Buch von Boris Gloger draußen mit dem Titel: Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind. Und in der Tat ist das Schätzen in Scrum eines der schwierigeren Themen.
Wenn sich viele auch schnell an Timeboxing und die Scrum-Meetings an sich gewöhnen, ist das Schätzen doch eines der Themen, die ein echtes Umdenken erfordern.
Scrum fordert das strikte Denken in Benefits für den Anwender. Auch wenn das Denken in Funktionen dem Softie in der Regel nicht schwer fallen sollte, findet man doch vielfach eher das Schichtendenken. Da gibt es den Datenbank-Spezialisten, den Middleware-Experten, den GUI-Designer. Und klassischerweise bastelt jeder in seiner Schicht, bis man nach Monaten im großen Integrationstest mal alles zusammen testet. In Scrum aber liefern wir nach jedem Sprint ein potentiell auslieferbares Produkt.
Warum Funktionalität schätzen?
In seinem Buch erklärt Gloger in Kapitel 7 das Schätzen der User Stories. Er versucht klar zu machen, warum er das Schätzen der Funktionalitätsgröße als sinnvollste Art des Schätzens von User Stories sieht.
Funktionalität ist konstant
Was etwas tut, ändert sich nicht über die Zeit. Es kann höchstens sein, dass es nicht gut genug beschrieben ist bzw. zwei Seiten ein unterschiedliches Verständnis der Funktionalität haben.
Betrachtung aus der Perspektive des Users
Der Entwickler ist gefordert, in den Anforderungen des Kunden zu denken. Das führt zu einem besseren Verständnis dessen, was entwickelt werden soll und zu einer engeren Kommunikation mit dem Product Owner.
Schätzungen sind auch für Nicht-Techniker transparent
Die Größe der Funktionalität ist auch für Nicht-Techniker nachvollziehbar. Bei der Frage, ob mein Außenspiegel oder das verbaute Infotainment-System mehr Funktionalität bietet, kann auch der Fahrer des Autos mitreden, ohne dass er weiß, wie man Autoradios oder Außenspiegel entwickelt.
Warum nicht Aufwand?
Vielfach kommt der Wunsch der Entwickler, doch den Aufwand der Stories schätzen zu wollen. Das ist verständlich, das sind sie gewöhnt. Vermutlich steckt dahinter, dass ein Entwickler schätzen möchte, wie groß der Umfang seiner Aufgaben sein wird.
Das wiederum hieße aber, dass schon zu Beginn klar ist, wer eine Aufgabe ausführt. Diese Vorstellung widerspricht aber dem Teaming-Gedanken in Scrum. In der Realität zeigt sich allerdings, dass sich das Ideal des „Jeder-kann-alles“ gerade in Teams aus gemischten Disziplinen nicht leicht umsetzen lässt, meine ich.
Dennoch müsste auch klar sein, was denn konkret zu tun ist. Bei der Klärung der User Stories geht es aber zunächst nur um das was. Beim Schätzen von Aufwänden werden oft Risikoaufschläge hinzugerechnet und beeinflussende Störungsfaktoren lassen sich nicht vorraussagen. Die Zahlen sagen letztlich nichts aus.
Sinnvoll auf Projektebene
Aufwandsschätzungen machen Sinn auf einem höheren Abstraktionslevel. Dort kann ich ein Projekt mit einem Vorgängerprojekt vergleichen, vielleicht auch ein Epos mit einem ähnlichen Epos.
Natürlich verlangen viele externe Kunden ein Angebot mit konkreten Zahlen, so dass ich in der Regel auch gezwungen bin, einen Preis auf Basis einer Aufwandsschätung abzugeben. Diese erhält man aber durch Analogien.
Nicht sinnvoll auf Detailebene
Für Mini-Funktionalitäten wie User Stories mache es aber keinen Sinn, den Aufwand zu schätzen, so Gloger. Sie seien zeitintensiv und sagten nichts über die Durchlaufzeit einer Story. Scrum ersetzt Planung durch Statistik.
Warum nicht Komplexität?
Auch der Begriff der Komplexität ist eher ungeeignet. Ob etwas „schwierig“ ist, hängt von der Person ab, die die Aufgabe durchführen soll. Etwas, das mir schwer fällt, kann meinem Kollegen leicht fallen.
Gloger bemüht eine Definition aus der Physik:
Eine physikalische Größe ist eine quantiativ bestimmbare Eigenschaft eines physikalischen Objekts, Vorgangs oder Zustands.
Da kann ich gut mitgehen. Es geht darum, eine Eigenschaft der User Story zu bestimmen, möglichst unabhängig von allem anderen. Die Aufwands- und Komplexitätsschätzung bezieht immer den Faktor Mensch mit ein. Das Schätzen von Funktionsumfängen kommt der Forderung nach Quantität am nächsten.
Magic Estimation
Während Planning Poker recht bekannt ist, plädiert Gloger für eine Methode, die er Magic Estimation nennt. Zusammenfassend zeichnet sich Magic Estimation durch folgende Eigenschaften aus:
- auch mit vielen Schätzern und für viele Stories anwendbar
- schnellste Methode (70 Stories von 10 Personen in 20 Minuten schätzbar)
- somit lässt sich jede Woche das gesamte Backlog bewerten
- benötigt viel Platz (großer Raum, Flur)
Zur Vorbereitung:
- Jede Story gut lesbar auf ein DIN A4 Blatt drucken mit Angabe des Rangs
- Eine Bewertungsskala auslegen (Fibonacci-Zahlen, Tiersymbole, T-Shirt-Größen o.ä.)
- Jedes Teammitglied erhält etwa die gleiche Anzahl an Story-Blättern.
Die wichtigste Regel bei der Duchführung lautet: Keiner spricht, alle agieren schweigend! Es läuft dann wie folgt ab:
- Man liest seine Stories der Reihe nach durch und legt sie zu der Zahl, die seiner Meinung nach die Funktionsgröße der Story am besten repräsentiert. Zwischenwerte sind nicht erlaubt.
- Sobald man alle seine Stories zugeordnet hat, fängt man an, die Stories der anderen umzusortieren.
- Der Product Owner beobachtet das Geschehen und markiert die Blätter, die öfters bewegt werden. Das scheinen die Stories zu sein, bei denen es noch Uneinigkeit bzgl. der erwarteten Funktionalität gibt.
Übung
Ich habe die Methode mal ausprobiert mit Gegenständen aus dem Haushalt. Der Vorteil dabei ist, dass sich die Teammitglieder eher gedanklich in der Rolle der Anwender wiederfinden. Das Ergebnis war wirklich erstaunlich. Innerhalb von Minuten hatten wir eine Eingruppierung der einzelnen „Stories“. Probieren Sie es mal aus!
Hier finden Sie meine Blätter zum Ausdrucken und Ausschneiden:
Zusammenfassung
Im folgenden noch eine Zusammenfassung des Kapitels, die natürlich nicht den Kauf des Buches ersetzen kann.
Und nun viel Spaß beim magischen Schätzen!