Agiles Schätzen mit Planning Poker

„Planning Poker“ ist eine der empfohlenen Möglichkeiten im Scrum, in einem Team schnell zu einer gemeinsamen Abschätzung über die Komplexität einer Aufgabe zu kommen. Das Ziel ist die verlässlichere Aussage darüber, was das Team in einem bestimmten Zeitraum leisten kann. Das schafft Planungssicherheit, die letztlich allen Beteiligten nützt.

Laut domendos consulting können „nur 16 % der untersuchten IT-Projekte als erfolgreich eingestuft werden (Studie der Universität Oxford 2003)“. Das ist nicht verwunderlich, denn es ist nicht einfach, die Zukunft vorherzusagen. Wer länger im Projektgeschäft tätig ist, hat oft genug erfahren, dass Zeitabschätzungen recht problematisch sind — und selten zutreffend. Würde man die tatsächlich benötigte Zeit einer Aufgabe akribisch erfassen und mit der ursprünglichen Schätzung vergleichen, würden vermutlich die meisten Aufgaben länger gedauert haben als geschätzt. Genau genommen haben sie natürlich längst länger gedauert, aber durch die Überprüfung hätte man es dann endlich bemerkt! Paradoxerweise wird jedoch im Vorfeld eines Projektes fast immer eine detaillierte Vorhersage der benötigten Zeit gefordert, wohl wissend, dass die Verlässlichkeit nur beschränkt vorhanden ist. Die Gründe dafür liegen sicher zum Teil in der Unwissenheit derer, die dies fordern. Böse Zungen könnten natürlich auch vermuten, dass die mangelnde Verlässlichkeit gerade denen willkommen ist, die nachträglich gerne Druck aufbauen wollen, weil mal wieder etwas nicht geschafft wurde.

Nun kann man verstehen, dass ein Auftraggeber wissen möchte, wie lange etwas dauert, um den Vorgang mit anderen Abteilungen wie z.B. dem Vertrieb abstimmen zu können. Außerdem muss das Budget entsprechend geplant werden, um das Projekt überhaupt finanzieren zu können.

Was dabei meiner Ansicht nach oft übersehen wird, ist die Unterschiedlichkeit der Aufgaben. Wenn ein Fertigungsprozess geplant wird, lässt sich anhand von Erfahrungswerten und gemessenen Zeiten recht bald herausfinden, wie lange der Bau einer Anlage benötigt. Schließlich sind ähnliche Anlagen schon oft genug gebaut worden, so dass man über einigermaßen verlässliche Zahlen verfügt. Im Bereich der Softwareentwicklung ist allerdings fast jede Software zunächst ein Prototyp, und nur selten ist eine vergleichbare Software schon mehrfach erstellt worden. Daher müsste Softwareentwicklung eher mit dem Bau von Prototypen verglichen werden als mit üblichen Fertigungsprozessen.

Hinzu kommt, dass auch das Team, das die Software entwickeln soll, vielleicht noch gar nicht zusammengearbeitet hat. Folglich sind weder von der Tätigkeit her noch von der Teamzusammensetzung wirklich verlässliche Zahlen zu bekommen.

Story Points

Im Scrum wählt man daher einen anderen Ansatz, der sich mehr an dem orientiert, was der Programmierer tatsächlich abschätzen kann: Dem Schwierigkeitsgrad einer Aufgabe. Hierzu wird eine dimensionslose Zahl verwendet, der Story Point. Dies führt alsbald zu verlässlicheren Abschätzungen als wenn man zu Beginn jeden eine „gefühlte Dauer“ abgeben lässt.

Das Konzept der Story Points basiert darauf, dass nicht die voraussichtlich erforderliche Zeit für die Umsetzung einer Aufgabe abgeschätzt wird, sondern die Aufgaben bezüglich ihrer Komplexität zueinander in Beziehung gesetzt werden. Aussagen wie „Story A ist dreimal so komplex wie Story B“ sind hier also zielführender als die Behauptung, man würde für Story A 12 Stunden und für Story B 4 Stunden brauchen. Denn es könnten genausogut auch 9 und 3 Tage sein.

Agiles Schätzen mit Planning Poker

In einem Planungs-Meeting zu Beginn eines „Sprints“ (in anderen Konzepten auch „Iteration“ genannt) werden die anstehenden Aufgaben von den Teammitgliedern zunächst besprochen, um gemeinsam mit dem Auftraggeber („Product Owner“) zu einem korrekten Verständnis dessen zu kommen, was gemacht werden soll.

Wenn die Story hinreichend besprochen ist und jeder eine Vorstellung von dem Aufwand hat, schätzt jeder für sich die Story Points ab. Er wählt die entsprechende Karte und legt sie  zunächst verdeckt vor sich auf den Tisch. Wenn sich alle entschieden haben, werden alle Karten auf einmal umgedreht. So wird erreicht, dass keiner von einer schnellen oder vermeintlich wichtigeren Meinung eines anderen beeinflusst wird und sich wirklich ganz auf sein Gefühl verlassen kann. Liegen die Schätzungen zu weit auseinander, tauschen sich die beiden Teilnehmer mit den Extrempositionen über ihre Gründe aus. So entsteht schnell ein konstruktiver Dialog über den Problemkreis. Planning Poker hat also zu einem gewissen Teil durchaus etwas mit dem realen Poker zu tun, indem die Kollegen ihre Karten erst dann aufdecken, wenn der richtige Zeitpunkt gekommen ist :-)

Hat das Team alle voraussichtlich zu schaffenden Aufgaben („Stories“) geschätzt, werden die Story Points der Aufgaben in der Reihenfolge ihrer Wichtigkeit addiert. Sobald das Limit erreicht ist, das das Team zuvor auf der Grundlage der in den bisherigen Sprints geschafften Stories („Velocity“) abgesprochen hat, hört man auf. Dies ist dann die Menge an Aufgaben, die das Team voraussichtlich in diesem Sprint schaffen wird.

Verlässliche Prognosen

Da die Länge eines Sprints ebenfalls im Vorfeld festgelegt wurde und innerhalb eines Projektes konstant bleibt, weiß der Auftraggeber dann, was das Team bis zum Ende des Sprints voraussichtlich schaffen wird. Die Velocity wird dann am Ende des Sprints aus der Summe der bis dahin tatsächlich geschafften Aufgaben ermittelt und bildet dann zusammen mit den bisherigen Daten die Grundlage für die weitere Planung des nächsten Sprints, der wieder mit einer Runde „Planning Poker“ beginnt. Da die Datenmenge für diese Planung mit jedem mal anwächst, entsteht so im Laufe der Zeit eine immer verlässlichere Aussage über die Frage, „was schaffen wir im nächsten Sprint?“

Ich habe mir vor einiger Zeit ein paar „Spielkarten“ bei der schwedischen Firma Crisp bestellt. Hier steht noch einiges zu dem Prozedere geschrieben (englisch).

 

Foto: iStockphoto.com/Jeremiah Deasey


SmallInvoice Logo

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Schreibe einen Kommentar

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

drei + elf =