Für viele ist es eine eher unbeliebte Aktivität im Rahmen eines Softwareentwicklung-Projekts – für mich schon deshalb ein Lieblingthema: Schätzen mit der passenden Schätzmetrik und Schätzmethode. In vielen Projekten erlebe ich, dass es sogar immer wieder zum Streit kommt, ob und wie richtig agil geschätzt wird oder werden soll. Dabei muss es doch gar nicht nervend oder anstrengend sein: Mit den richtigen Schätzmethoden und der richtigen Vorbereitung auf einen Schätztermin ist es nämlich recht simpel, auch schnell selbst eine große Anzahl von Anforderungen zu schätzen. Geschätze Anforderungen zu haben, hat nur Vorteile:
Einmal, wenn es darum geht, auf einen bestimmten Termin etwas abzuliefern. Auf der anderen Seite aber, um einen bestimmten Einstieg in die Fach-Diskussion über eine Anforderung zu bekommen, bei der jeder Teilnehmer versteht, um welche Dimensionen einer Anforderung es sich handelt und in welcher Relation diese zum Gesamtprojekt steht.
Drittens und eigentlich am wichtigsten, weil agile Methoden empirische Methoden sind, also vermessen werden können (und sollen). Zum Beispiel sollte man messen, wie viele Storypoints in welcher Zeit ausgeliefert werden konnten. Das hat mit Statistik zu tun: Nach ein paar Messpunkten (also in der Regel nach einigen Sprints) wird man sehen, inwiefern und wann es Abweichungen gegeben hat. Daher ist es in jedem Fall eine gute Idee, nach einer Iteration mit diesen Daten zu arbeiten, um zu erkennen, dass man Schwankungen vermeiden sollte. Ziel ist schließlich, voraussagen zu können, wie viel man innerhalb einer definierten Planungs- und Umsetzungsphase garantiert abliefern können wird.
Was kann man also tun, wenn es mal wieder darum geht, das Schätzen als neue Routine einzuführen? Und auf jeden Fall von den personenbezogenen Stundenschätzungen weg will?
Ganz einfach: Tageseinheiten als Orientierung nehmen
Weil es immer um Lieferung auf Termine geht und weil es Menschen tendenziell eher schwerfällt, Aufgaben mit einer detaillierten Zeiteinheit wie Stunden zu bewerten und dabei genau vorherzusagen, was alles passieren könnte, schlage ich dafür vor, Zeitbereiche zu definieren. Bei dieser Schätzgrösse teilen wir den Tag in vier Zeitbereiche:
– Bis zum Frühstück
– Bis zum Mittagessen
– Bis zur Tea Time
– Bis zum Feierabend
Zeitschätzungen mit diesen Zeitbereichen sind einfach zu bewerkstelligen. Die einzige Frage ist: Hast Du eine Aufgabe bis zum Frühstück oder bis zur Tea Time fertig?
Diese Methode eignet sich jedoch nur kurzfristig zum gemeinsamen orientieren für die Fertigstellung von Aufgaben.
Königsweg: Storypoints schätzen
Langfristig möchte ich mit meinen Teams aber auf jeden Fall auf die Storypoints-Schätzung hinaus. Storypoints sind für mich das Mittel zur Wahl bei der Schätzung von agilen Projekten. Mit Storypoints bewertet man nämlich nicht alleine die Zeitdauer einer Aufgabe, sondern den Anteil einer Anforderung am Gesamtumfang. Die Summe aller Storypoints aller Aufgaben müsste also den Gesamtumfang eines Projekts beschreiben, sie sind also immer nur etwas im Verhältnis zu etwas anderem im gleichen Projekt. Storypoints werden meistens durch eine wachstumsorientierte Zahlenreihe gebildet, die der Fibonacci-Reihe entspricht (1, 2, 3, 5, 8, 13, …).
T-Shirt Grössen
Wenn ich größere Funktionsblöcke, wie z.B. Epics schätzen lassen will, nutze ich keine Storypoints sondern T-Shirt Größen. Diese Schätzgröße ist mit den Storypoints eng verwandt und funktionieren im Prinzip genauso. Zum Unterschied zu Storypoints wird hier nicht ein konkreter Wert geschätzt, sondern ein Bereich von Storypoints. Die folgende Tabelle zeigt eine Aufteilung, die ich in vielen Projekten bereits erfolgreich angewandt habe:
| T-Shirt Größe | Storypoints-Bereich | T-Shirt Größe | Storypoints-Bereich |
|---|---|---|---|
| S | 1 – 13 | XL | 69 – 100 |
| M | 14 – 29 | XXL | 101 – 150 |
| L | 30 – 68 |
Analog zu den Storypoints gilt: Je grösser das T-Shirt, desto unschärfer die Schätzung. Aus meiner Erfahrung entspricht eine solche Schätzung eher der Realität, denn Schätzungen von großen Funktionsblöcken fallen mir zumindest tendenziell schwerer, als Schätzungen von kleinen, abgegrenzten Funktionen.
Schätz-Spaß beim Planning Poker
Wie kann ich aber nun eine solche Schätzung durchführen, ohne dass dies zu einer öden Veranstaltung verkommt? Wie könnte es einfacher gehen, als mit einem Kartenspiel. So kommt tatsächlich manchmal auch etwas wie Spaß auf – wohlgemerkt bei einer Angelegenheit, die fast nicht wichtiger sein könnte. Jeder Teilnehmer bekommt also einen Satz Karten mit den entsprechenden Storypoint-Werten (z.B. 1, 2, 3, 5, 8, 13,…) in die Hand; nach Vorstellung der Inhalte einer Story durch den Product Owner, einer anschliessenden Diskussion über fachliche und auch technische Aspekte, gibt jeder aus dem Entwicklungsteam eine Schätzung ab, indem er die Karte mit dem entsprechenden Wert verdeckt auf den Tisch legt. Auf Kommando werden die Karten umgedreht und die Werte verglichen – wie beim Poker. Ziel ist aber nicht, zu gewinnen, sondern auf einen einheitlichen Wert zu kommen. Kommt das Team auf einen gemeinsamen Wert, weil alle die Karte mit dem gleichen Wert gewählt haben, dann wird die Anforderung damit bewertet. Wenn es zu Differenzen kommt, erklären die Schätzer der Extremwerte jeweils, warum sie genau diesen Wert gewählt haben und keinen anderen. Schließlich geht es in die nächste Schätzrunde. Kommt es auch nach der zweiten Runde nicht zu einem einheitlichen Ergebnis, sollte die Story zurückgestellt und noch einmal überarbeitet werden – offenbar gibt es zu viele Unklarheiten für eine einfache Bewertung. Das ist aus meiner Erfahrung sehr effektiv und macht auch dem letzten Schätzmuffel ein bisschen Spaß.
Im nächsten Teil werde ich beschreiben, wie ich damit umgehe, wenn es eine große Anzahl von Anforderungen in kurzer Zeit oder sogar auf ein Mal zu schätzen gilt!
