Schätzmethoden in der agilen Praxis

Gerade für den agilen Projektmanager lohnt sich ein Blick auf einige empirische Studien, wie weit verschiedene Schätzverfahren verbreitet sind. Eine gute Übersicht findet sich in Molokken & Jorgensen, 2003. Auf Basis dieser Daten kann man auf folgende grobe Verbreitung schließen:

 

Abb. 3 Verbreitung der Schätzverfahren[1]

Zwischen 70 % und 80 % der Befragten schätzen die Aufwände mit der Expertenschätzung. In vielen Publikationen werden aber fast umgekehrt proportional die Expertenschätzung nur zu ca. 17 % behandelt.[2] Hier scheint die unternehmerische Praxis weit entfernt von der Theorie zu liegen. Auf die Frage warum die Expertenschätzung so weit verbreitet ist bietet Jorgensen in derselben Studie einige Antworten an. Es gibt danach keinen Beweis dass algorithmische Verfahren genauer als empirische Verfahren bzw. als Expertenschätzungen sind. Die 15 verglichenen Studien zeigen, dass gerade die Expertenschätzung in der Genauigkeit der Schätzungen weit vorne liegt. Fünf Studien sahen die höchste Genauigkeit in der Expertenschätzung, drei in algorithmischen Verfahren und zwei im Analogieverfahren. Die restlichen fünf fielen Unentschieden aus.

Die Expertenschätzung als Einstiegspunkt für zuverlässige Schätzungen

Die Expertenschätzung ist ein Prognoseverfahren bei dem das Wissen eines ausgewählten Personenkreises genutzt wird.  Die Expertenschätzung ist gleichzeitig die am weitesten verbreitete Schätzmethode. Sie gilt als weniger aufwändig aber dafür ist sie nicht standardisiert weil standardisierte Verfahren auf einem definierten Prozess mit geprüften und einheitlichen Eingangsparametern beruhen.[3]

Der Expertenschätzung sollte zu Beginn zumindest ein einfaches Regelwerk wie sie in Conboy’s Cost Estimation in Agile Software Projects[4] und Jorgensens Practical Guidelines for Expert-Judgement-Based Software Effort Estimation[5] beschrieben, vorgelegt werden.

  • Keine Vermischung von Schätzung, Planung und Angebotserstellung
  • Beteiligung von Entwicklern und Managern
  • Beteiligung von Schätzern mit ähnlichen Projekterfahrungen
  • Schätzergebnisse kombinieren
  • Begründung jeder Schätzung
  • Erst schätzen, wenn die Anforderungen festgelegt sind
  • Dokumentation der Erfahrungen.

Warum Schätzen in abstrakten Maßen nicht ausreicht

Ein wichtiger Unterschied zu klassischen Schätzverfahren liegt zunächst in der Unterscheidung zwischen Komplexität und Aufwand. In vielen Büchern der agilen Softwareentwicklung wird empfohlen die User-Stories in Komplexität zu schätzen weil diese besser zu handhaben sind. In der agilen Projektpraxis wurde aber die Erfahrung gemacht, dass man sich zwar immer auf bestimmte User-Stories bzw. Komplexitäten „committet“ (geeinigt) hat, jedoch war für das Multiprojektmanagement der Nutzen oder der Aufwand eines Komplexitätspunktes nicht greifbar. Deswegen ist die Messung der Team Velocity[6] unumgänglich um später sagen zu können: „ Unser Team schafft 74 Story-Points pro Sprint (10 Tage)“. Der Umfang eines fachlichen Features lässt sich in einem abstrakten Komplexitätsmaß (z.B. Function Points) ausdrücken. Der Aufwand zur Umsetzung leitet sich dann aus weiteren Faktoren ab. Die Umrechnung in Aufwand muss somit auch mit in die Schätzung einfließen.

Planning Poker auf Basis von Story Points

Die Planning Poker Methode ist eine sehr einfache Methode, um Backlog Items oder User Stories zu schätzen und findet im SCRUM seine Anwendung. Sie nimmt verhältnismäßig kurze Zeit in Anspruch und beruht auf der Expertenschätzung. Nach dem die Anforderungen mit Hilfe einer Story Map in User Stories zerlegt worden sind, werden diese in Story Points geschätzt, die relative Schätzungen der Komplexität, des Aufwands oder der Dauer einer Story sind. Die Schätzung muss im Team erfolgen die dann auch verantwortlich für diese Schätzung ist.[7] Planning Poker wird mit Planning-Poker-Karten gespielt.  Dazu bekommt jedes Teammitglied ein Kartenset die mit der unreinen Fibonacci-Reihe nach Cohn (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) nummeriert sind. Eine User Story wird dann ausgewählt und vom Product Owner beschrieben und eventuelle Fragen geklärt. Wenn alle Fragen geklärt sind, wählt jedes Teammitglied eine Karte aus, die den Wert repräsentiert, der diesem Teammitglied als korrekt erscheint. Erst wenn alle Mitglieder sich entschieden haben, werden die Karten gleichzeitig aufgedeckt. Die beiden Teammitglieder mit dem höchsten und dem niedrigsten Schätzwert erläutern wie sie auf die jeweiligen Werte gekommen sind. Durch diese Erläuterungen und dem Informationsaustausch werden Dinge klargestellt die evtl. noch geklärt werden müssen. Die Schätzung wird daraufhin wiederholt. In der Regel sind die Zahlen dann angeglichen. Der Moderator fragt dann, ob man sich auf den am meisten genannten Wert einigen kann. Ist dies der Fall wird die User Story mit den Story Points versehen. Dieses Verfahren gibt gute Schätzwerte ab, jedoch sollte zu Beginn einer solchen Schätzung die einzelnen Werte klar definiert werden. Eine gute Möglichkeit ist es, wenn das Team sich auf eine Beispielhafte User Story mit einem Story Point einigt. Diese „Prototyp Story“ muss auch nach dem Zeitaufwand bewertet werden. Dies erfolgt durch Erfahrungswerte aus früheren Sprints oder der Team Velocity.



[1] (Molokken & Jorgensen, 2003)

[2] Vgl.  (Jorgensen, A Review of Studies on Expert Estimation of Software Development Effort, 2004)

[3] (Buglione & Abran, 2007, S. 273)

[4] Vgl.  (Conboy & Keaveney, 2005)

[5] Vgl.  (Jorgensen, 2005)

[6] Team Geschwindigkeit

[7] Vgl. (Cohn, 2010, S. 107)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert