Ü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 Estimation Game" (Blockmann, 2007). Der Vorteil dieser Methode liegt darin, dass eine große Menge von User Stories innerhalb kurzer Zeit geschätzt werden kann.

Im Folgenden beschreiben wir unsere Erfahrungen mit dem Team Estimation Game, das wir in einem Teilprojekt mit einem Umfang von zehn Mannjahren verwendet haben. Wir konnten mit dieser Methode 250 User Stories innerhalb einer zweistündigen Sitzung analysieren. Die Ergebnisse halfen uns wesentlich dabei, das Projekt termingerecht abzuschließen und gleichzeitig die vorgesehene Funktionalität fast vollständig zu realisieren.

Das Projekt: Software-Entwicklung nach Scrum

Unser Teilprojekt hatte die Aufgabe, eine bestehende, webbasierte Software-Lösung als Desktop-Applikation neu zu implementieren und um einzelne Leistungsmerkmale zu erweitern. Diese Anwendung unterstützt die technische Qualitätssicherung, die während des Betriebs eines komplexen Medizinprodukts regelmäßig durchgeführt werden muss. Die Bedienungsoberfläche war neu zu entwickeln, während die Geschäftslogik auf eine neue technologische Basis übertragen werden sollte. Eine weitere, unverrückbare Randbedingung bestand darin, dass der Zeitrahmen vom Gesamtprojekt fest vorgegeben war.

Wir verfügten über drei Entwicklungsteams mit insgesamt 18 Entwicklern und Testern, einen Scrum Master und einen Product Owner. Die traditionelle Rolle des Projektmanagers ist in Scrum nicht vorgesehen; seine Aufgaben teilen sich im Wesentlichen der Scrum Master und der Product Owner. Die Entwicklung wurde in Sprints mit einer Dauer von jeweils vier Wochen untergliedert. Der Product Owner führte ein Product Backlog mit allen User Stories, die in der Reihenfolge ihrer Implementierung angeordnet waren.