Die Alternative zum Planning Poker: Das Team Estimation Game

In der agilen Software-Entwicklung wird der Leistungsumfang üblicherweise mit User Stories beschrieben und der jeweilige Entwicklungsaufwand in der relativen Einheit "Story Point" geschätzt. Eine Methode für die Aufwandsschätzung mit Story Points stellt das sog. "Team Estimation Game" dar. Tord Bjoersne, Ivan Kostial und Klaus-Dieter Schmatz beschreiben ihre Erfahrungen mit dieser Methode. Für ein Teilprojekt mit einem Umfang von zehn Mannjahren konnten sie mit dem Team Estimation Game 250 User Stories innerhalb einer zweistündigen Sitzung analysieren. Die so erhaltenen Schätzungen stellten sich als überraschend robust heraus und waren für die weitere Projektsteuerung überaus nützlich. Darüber hinaus förderte der gemeinsame Workshop den Wissensaustausch im Team und erwies sich sogar als gutes Team-Building-Event.

Üblicherweise erstellt der Projektmanager am Beginn eines neuen Projekts eine Aufwandsschätzung. Der Auftraggeber verwendet diese Abschätzung, um über die Freigabe oder den Abbruch des Projekts zu entscheiden. Im weiteren Projektverlauf dient sie als Ausgangspunkt für die Ressourcen- und Zeitplanung. Wegen der Tragweite dieser Entscheidungen neigen viele Organisationen dazu, sehr viel Zeit und Mühe in die Aufwandsschätzung zu investieren.

Trotz solch detaillierter Aufwandsschätzungen dauern viele Entwicklungsprojekte länger als geplant oder sie liefern nicht die erhofften Ergebnisse. Dieses Risiko liegt in die Natur von Entwicklungsprojekten. Schließlich sollen sie etwas Neues schaffen, das es vorher noch nicht gab. Da somit verlässliche Erfahrungswerte fehlen, lässt sich nicht mit Sicherheit vorhersagen, wie lange die Realisierung dauern wird.

Die agile Methodik zeigt einen Weg auf, das Bedürfnis des Auftraggebers nach vorhersagbaren Resultaten mit den Unwägbarkeiten in Einklang zu bringen, die sich unweigerlich während der Realisierungsphase einstellen. Die Erreichung der Projektergebnisse wird dabei in so genannte "Sprints" unterteilt (Iterationen). Jeder Sprint ist so ausgelegt, dass er neue Funktionen umfasst, die einen echten Kundennutzen haben. Die Funktionen mit dem höchsten Wert für den Kunden werden möglichst in den ersten Sprints des Projekts entwickelt. Auch wenn das Projektteam bis zum Projektabschluss nicht alle ursprünglich geplanten Funktionen fertigstellen kann, so entwickelt es doch mit hoher Wahrscheinlichkeit ein für den Kunden nützliches Produkt.

Voraussetzung für dieses Vorgehen ist, dass der gesamte Funktionsumfang in einzelne User Stories unterteilt wird, deren Umfang individuell abgeschätzt werden kann. Die wichtigste Messgröße dabei ist der relative Umfang dieser User Stories (vgl. Wirdemann, Projekt Magazin 2/2010), d.h. der Umfang einer User Story im Vergleich zu den anderen. Der Product Owner kann diese Information heranziehen, um das Product Backlog zu priorisieren, indem er den Umfang einer User Story gegen ihren Kundenwert abwägt und die User Stories mit dem besten Kosten/Nutzen-Verhältnis möglichst weit oben einsortiert.

Wir haben uns dafür entschieden, den Umfang der User Stories in der Einheit "Story Points" mit einer vorgegebenen Werteskala (s.u.) abzuschätzen. Nach unserer Auffassung ist es am besten, die Story Points nicht als absoluten Messwert, sondern als relative Größe zu verstehen. Das heißt, die Realisierung einer User Story mit 8 Story Points wird ungefähr dreimal solange dauern wie die Realisierung einer User Story mit einem Umfang von 3 Story Points, eine absolute Dauer für die Realisierung kann aber zunächst nicht angegeben werden.

Für die Abschätzung der Story Points gibt es neben dem relativ zeitaufwendigen "Planning Poker" (vgl. Linssen, Projekt Magazin 10/2012) das von Steve Blockmann entwickelte "Team

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 9 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link