Aus der agilen Methodenkiste: Aufwand schätzen

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).

Die Auswirkungen, wenn man Schätzungen als „Verpflichtung“ betrachten würde, wären fatal, wie die Praxis – auch außerhalb des agilen Umfeldes – immer wieder aufzeigt. Bewusst oder unbewusst werden zum Beispiel Qualitätskriterien unterlaufen, um im geschätzten Aufwandsrahmen zu bleiben u. ä., und letztendlich damit das Hauptziel gefährdet: die Kundenzufriedenheit.

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

 
Im Folgenden stellen wir zwei weitverbreitete Schätzmethoden vor, die häufig zur Anwendung kommen. Einmal die sogenannte T-Shirt-Methode und zum anderen das sogenannte Planning Poker:

T-Shirt-Methode

T-Shirt_Methode
Storypoints nach T-Shirt-Größen
Eine der einfachsten Schätzmethoden ist die sogenannte T-Shirt-Methode. Dabei werden die bekannten T-Shirt-Größen (S, M, L, XL, XXL) zugrunde gelegt und als „Schätzwerte“ verwendet, um die einzelnen User Storys in Beziehung zu setzen. Vorteil hierbei ist, dass sich auf Basis der Metapher mit den T-Shirt-Größen relativ schnell ein gemeinsames Verständnis herstellen lässt. Jeder hat eine ungefähr eine Vorstellung was S oder XL bedeutet und in welcher Beziehung die Größen zueinander stehen.

Planning Poker

 
Etwas aufwendiger aber weitverbreitet ist das sogenannte Planning- Poker. Das Planning-Poker hat sich bewährt und geht auf James Grenning zurück, der die Methode 2002 erstmalig vorstellte. Mike Cohen, ein agiles Urgestein, hat die Methode 2008 mit seinem damals erschienen Buch populär gemacht, die dann rasant Verbreitung in der agilen Szene fand. Die Planning-Pokerdecks bedienen sich der sogenannten Fibonnacci-Folge. Einer Zahlfolge, bei der die Summe zweier aufeinanderfolgender Zahlen die unmittelbar danach folgende Zahl ergibt.
Bildquelle: Wikimedia Commons, public domain
Jedes Teammitglied erhält einen Satz Planungskarten. Der Scrum Master (in scrumgeführten Projekten) leitet das Team an.
Die Regel sind relativ einfach zusammengefasst:
  1. 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.
  2. 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.
  3. 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.
  4. 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

Wombat aus Brehms Thierleben (1829 bis 1884), Wikimedia Commons, gemeinfrei

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

Haben Sie Fragen oder wollen über Fragen der praktischen Anwendung mit Gleichgesinnten diskutieren? Schreiben Sie uns eine Nachricht, kommentieren Sie hier im Blog oder nutzen Sie einfach unsere neue Facebook-Gruppe, die wir zum Zweck des Austauschs und der kollegialen Beratung eingerichtet haben.

Autor: Thomas Michl

Projektmanagement | Agile | Lean | Social Media | Selbstmanagement | Kommunalpolitik | Dipl-Verw.Wiss. | MBA | Europäer | Irland-Fan | Threema-ID WDMEXHA7

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s