

Planning Poker ist eine effektive Methode zur relativen Aufwandsschätzung von User Storys bzw. Aufgaben in kleinen Gruppen. Die agile Herangehensweise ermöglicht eine direkte Bestimmung des Aufwands durch die Mitglieder des Umsetzungsteams. Die vorhandene Fachexpertise der einzelnen Personen wird eingesetzt, um ein zu schätzendes Thema in der Arbeitsgruppe aus unterschiedlichen Aspekten, Hintergründen und im Mehr-Augen-Prinzip zu bewerten.
Planning Poker ist eine effektive Methode zur relativen Aufwandsschätzung von User Storys bzw. Aufgaben in kleinen Gruppen. Die agile Herangehensweise ermöglicht eine direkte Bestimmung des Aufwands durch die Mitglieder des Umsetzungsteams. Die vorhandene Fachexpertise der einzelnen Personen wird eingesetzt, um ein zu schätzendes Thema in der Arbeitsgruppe aus unterschiedlichen Aspekten, Hintergründen und im Mehr-Augen-Prinzip zu bewerten.
Im Falle des Einsatzes einer Collaboration Plattform (Skype, Google Hang-out...) für verteilte Teams:
Die Methode wurde 2002 von James Grenning initiiert und von Mike Cohn (Eigentümer von "Mountain Goat Software") verbreitet (Lant, Michael: Estimate Story Size by Playing Agile Planning Poker, http://michaellant.com/2010/07/13/agile-planning-poker, zuletzt besucht am 10.8.2015.
Mountain Goat Software hält die eingetragene Marke auf Planning Poker Karten, sowie auf die Standard-Zahlenwerte: 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100 (https://www.mountaingoatsoftware.com/agile/planning-poker/license, zuletzt besucht am 10. Juni 2015).
Die Methode wird primär dem agilen SCRUM-Vorgehen zugeordnet, kann aber auch in klassischen Projektvorgehensweisen angewandt werden. Aufgrund des einfachen Settings und dem direkten Feedback im Kreis der verantwortlichen Bearbeiter werden anspruchsvolle, nicht vollständig spezifizierte Aufgaben zu einem beliebigen Zeitpunkt des Projektverlaufs diskutiert und deren Aufwand bewertet. Planning Poker liefert nicht nur einen, dem Teilnehmerkreis entsprechend qualifizierten Erfahrungswert, sondern fördert durch die Stimmabgabe auch die inhaltliche Identifikation der Teilnehmer mit der Aufgabenstellung.
Überprüfen Sie, ob die User Storys in der aktuellen Fassung und vollständig vorliegen. Stellen Sie sicher, dass alle zu behandelnden User Storys auf Moderationskarten gedruckt / geschrieben werden.
Achten Sie darauf, dass alle nachfolgenden Teamrollen besetzt sind:
Benennen Sie bei der Einladung zum Planning Poker das zu schätzende Vorhaben (Ihr Projekt).
Ergänzen Sie bei der erstmaligen Anwendung Hinweise zum Thema Planning Poker. Planen Sie bei einem mit Planning Poker unerfahrenen Team mehr Zeit ein, um Vorbereitungsrunden durchzuführen, bei denen die Teilnehmer die Methode lernen und einüben.
Der Product Owner präsentiert die Produkt/Projekt-Vision und stellt die thematischen Schwerpunkte des nächsten, zu schätzenden Sprints vor. Der Scrum Master stellt neue Teammitglieder und hinzugezogene Experten vor. Ferner erläutert er, dass mit Hilfe von ein bis zwei Einstimmungsrunden mit dafür geeigneten User Storys die "Kalibrierung", sprich das gruppenweite Verständnis zu Kartenwerten, erreicht wird.
Beschreiben Sie, je nach Vorkenntnissen der Teilnehmer, das Prinzip und die Funktionsweise von Planning Poker. Erklären Sie in jedem Fall die Aufgaben der einzelnen Rollen (s.o.) und erläutern Sie die Kartenwerte:
Wenn die Teilnehmer noch keine Erfahrung mit Planning Poker haben, sollten Sie zwei bis drei Vorbereitungsrunden durchführen, in denen Sie die Schritte 3 bis 6 mit ausführlichen Erläuterungen und mehr Zeit für die Schätzungen durchführen. Evtl. können Sie die so erzielten Schätzwerte bereits verwenden, andernfalls legen Sie die User Storys wieder in den zu schätzenden Pool zurück.
Der Product Owner wählt eine User Story für die nächste Schätzrunde aus und stellt sie vor. Für die ersten beiden Schätzrunden sollte er User Storys aussuchen, die sich gut für die "Kalibrierung" eignen (s.o.).
Der Moderator (z.B. der Scrum Master) frägt die Teilnehmer, ob alle die User Story vollständig verstanden haben. Bei Bedarf moderiert er die Klärung der Fragen. Wenn es zu keiner Klärung kommt, wird die User Story auf den nächsten Workshop vertagt. Der Product Owner muss die User Story bis dahin mit den entsprechenden Anforderungen verfeinern, damit er sie erneut einbringen kann.
Der Moderator fordert die Teilnehmer auf, die Schätzung vorzunehmen. Jeder Teilnehmer schätzt für sich den Aufwand für die betrachtete User Story, nimmt die Karte mit dem entsprechenden Zahlenwert (oder eine Sonderkarte) aus seinem Kartendeck und legt diese verdeckt vor sich ab. Der Moderator bestimmt, wie viel Zeit hierfür zur Verfügung steht, dies hängt insbesondere davon ab, wie die Entwickler mit der Methode vertraut sind.
Haben alle Teilnehmer den vorangegangenen Schritt ausgeführt, decken sie die Karten auf Kommando des Moderators auf. Begutachten Sie nun die Ergebnisse gemeinsam. Falls ein Teilnehmer eine der drei Sonderkarten "0", "?" oder "Kaffeetasse", gelegt hat, führen Sie die entsprechenden Schritte durch:
Besteht das Schätzergebnis ausschließlich aus Zahlenwerten, analysieren Sie die Häufigkeitsverteilung der Schätzwerte und gehen Sie dann wie folgt vor:
Kommt es bei einer User Story mehrfach zu starken Abweichungen, dokumentieren Sie den Sachverhalt im Protokoll. Anschließend empfiehlt es sich, die Mehrheitsentscheidung zu akzeptieren und auf der User-Story-Karte zu dokumentieren. Es steht Ihnen ebenfalls frei, die Schätzung der betroffenen User Story ein weiteres Mal durchzuführen.
Uneinigkeit bei der Vergabe der Story Points pro User Story ist ein klares Indiz für Unsicherheiten bezüglich der zugrunde liegenden Aufgabe. Kann diese durch weitere Informationen zur Aufgabe nicht aufgelöst werden, fließt der Hinweis zum mangelnden Konsens in die Dokumentation der User Story mit ein. Schätzen Sie die User Story im vorangeschrittenen Projekt neu (sofern verschiebbar) oder übergeben Sie die Unsicherheit bezüglich der Aufgabe an Ihr Risikomanagement.
Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.