Aufwandsschätzungen ist ein wichtiges Teilelement der (Projekt-)Planung. Das Problem bei Schätzungen jedoch ist, dass sie bestenfalls auf Erfahrungswerten der Vergangenheit basieren und damit mit einem hohen Unsicherheitsfaktor behaftet sind. Zu komplex sind die Einflussgrößen, um eine verlässliche Schätzung in abstrakten Zahlen liefern zu können. Daher werden Schätzungen – nach der agilen Lehre – ausdrücklich nicht als Verpflichtungen verstanden (im Gegensatz zum Sprintziel, das eine echte Verpflichtung darstellt).
Vergleichende Schätzung ist Trumpf
Ein wesentlicher Unterschied zwischen „klassischen“ und agilen Methoden bei der Schätzung ist auch, dass „agile“ Schätzungen in aller Regel keine abstrakten Schätzwerte zugrunde legen, sondern den jeweiligen Aufwand für eine Anforderung (User Story) untereinander in Beziehung setzen.
Aus der empirischen Erfahrung hat sich auch gezeigt, dass das vergleichende Schätzen zu deutlich schnelleren und besseren Ergebnissen führt. Ein einfaches Beispiel, das sich leicht ohne großen Aufwand durchexerzieren lässt, verdeutlicht, was damit gemeint ist. Fragt mensch eine Anzahl Menschen nach der Einwohnerzahl eine Reihe von Großstädten, dürfte sich diese sehr schwer tun. Werden sie jedoch gebeten, die Großstädte in entsprechende Reihenfolge zu bringen, trifft das Ergebnis erstaunlich oft zu.
Ein weiterer Unterschied des agilen Schätzens in Vergleich zur klassischen Aufwandsschätzung besteht darin, dass bei der Aufwandsschätzung grundsätzlich das ganze Team beteiligt wird. Die Schätzung findet im Dialog statt. Auf diese Weise wird das gemeinsame Verständnis im Team für die Aufgaben gestärkt, aber auch die Erfahrung aller Teammitglieder eingebunden und eine genauere Schätzung des Aufwands erzielt.
Storypoints als Maßeinheit
Gelegentlich werden Idealtage für die Schätzung verwendet. Allerdings hat sich in der Praxis gezeigt, dass die Schätzung in Idealtagen im Sinne von Fehlinterpretationen risikobehaftet ist. Zu sehr besteht hier wieder die Neigung, die Schätzung als Verpflichtung anzusehen. Daher haben sich als Maßeinheit die sogenannten Storypoints in vielen agilen Projekten durchgesetzt.
Storypoints sind eine abstrakte Maßeinheit, die sich nicht ohne Weiteres beziffern lässt. Was ein Storypoint ist, richtet sich dabei nach verschiedenen Faktoren, unter anderem der Komplexität und Struktur der User Storys (und Epics). Dabei geht es nicht um eine Zeiteinheit, sondern ausschließlich um die Struktur und Größenrelationen zueinander. Das hört sich zunächst schwierig an, erschließt sich aber zumeist aus der Praxis und den Schätzverfahren selbst.
Schätzmethoden
T-Shirt-Methode
Planning Poker
- Der Product Owner (PO) wählt aus dem Produktbacklog ein sogenanntes Produkt Backlog Inkrement (User Story) aus, das geschätzt werden soll, und stellt dieses dem Team vor.
- Die Teammitglieder haben jetzt die Möglichkeit, dem PO Fragen zu stellen und über die User Story zu diskutieren, um ein gemeinsames Verständnis über den zu schätzenden Umfang zu entwickeln.
- Jedes Teammitglied wählt im Anschluss eine Karte aus, die seiner Meinung dem Aufwand entspricht, und legt diese zunächst verdeckt vor sich hin. Haben alle Teammitglieder ihre Entscheidung getroffen, werden die Karten aufgedeckt.
- Sind die Schätzwerte identisch, besteht ein Konsens und damit ist die Schätzung für die ausgewählte User Story abgeschlossen. Gibt es keinen Konsens, wird im Team nochmals diskutiert, um die Hypothese zu prüfen und Missverständnisse auszuräumen. Danach wird erneut geschätzt. Dieser Schritt wird solange wiederholt, bis das Team einen Konsens beim Schätzwert erzielt.
#NoEstimates – ganz ohne Schätzung
Es gibt allerdings auch Stimmen, die ganz auf eine Aufwandschätzung verzichten. Diese argumentieren – obwohl sie Verständnis für den Hintergrund der Aufwandschätzung aufbringen – damit, dass der Prozess der Aufwandsschätzung unproduktiv sei. Hintergrund ist, wie auch schon eingangs erwähnt, dass Schätzungen eine hohe Unschärfe aufweisen. Insbesondere in Entwicklungsprojekten, die in aller Regel darauf abzielen, etwas Neues zu schaffen, gibt es keine verlässlichen Erfahrungswerte, auf die zurückgegriffen werden könnte.
Schätzungen sind daher per se fehlerbehaftet und Verschwendung, da sie darüber hinaus keine Wertschöpfung erzeugen. Sie sind „Wombat“ (= Waste of money, buget and time). Vertreter dieses Ansatzes setzen daher besonders ihr Augenmerk auf die kontinuierliche Auslieferung von fertigen Teilpaketen.
User Storys werden so klein wie möglich gehalten. So soll die notwendige Transparenz im Dialog zwischen Auftraggeber und Team hergestellt werden.
Kleiner Hinweis zum Schluss
Agile Verwaltung 
3 Kommentare zu „Aus der agilen Methodenkiste: Aufwand schätzen“