Suchen

So funktioniert die Aufwandseinschätzung in Scrum-Projekten

Mit Poker zum Projekterfolg

Seite: 2/3

Firmen zum Thema

Die Grundidee für eine Problemlösung: Bündeln der Erfahrungen

Das einzige brauchbare Mittel gegen diese Ungenauigkeit ist viel Erfahrung. Die Idee beim Planning Poker ist es, die Erfahrung mehrerer Software-Entwickler zu bündeln, um zu einer besseren Schätzung zu kommen.

Der erste, der seine Schätzung zu einem Teilproblem in der Runde nennt, beeinflusst automatisch die Schätzung der anderen Gruppenmitglieder.
Der erste, der seine Schätzung zu einem Teilproblem in der Runde nennt, beeinflusst automatisch die Schätzung der anderen Gruppenmitglieder.
(Bild: Kiko Jeminez/ Fotolia.com)

Theoretisch könnte man hierzu auch einfach drei Softwareentwickler mit den Anforderungsdokumenten in einen Raum setzen und die Schätzung gemeinsam erarbeiten lassen. Praktisch gibt es dabei aber leider ein allzu menschliches Problem. Und zwar entwickelt sich in jeder Gruppe innerhalb kürzester Zeit automatisch ein Mitglied zum Wortführer. Dieser gruppendynamische Aspekt gründet sich auf den verschiedenen Persönlichkeiten innerhalb der Gruppe.

Der Wortführer koordiniert die gemeinsame Arbeit an der Schätzung und beeinflusst dadurch die anderen Gruppenmitglieder. Weiterhin wird der erste, der seine Schätzung zu einem Teilproblem in der Runde nennt, automatisch die Schätzung der anderen Gruppenmitglieder beeinflussen. Von einer echten Bündelung der verschiedenen Erfahrungen kann also nur bedingt die Rede sein.

Gruppendynamik im Griff

Genau an dieser Problematik setzt die Methodik des Planning Poker an. Beim Planning Poker versammeln sich alle Software-Entwickler zusammen mit einem Moderator und idealerweise auch dem Product Owner an einem Tisch. Jeder Entwickler erhält ein Poker Deck mit den Schätzungen 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Diese Folge soll die Eigenschaft von Entwicklungstasks abbilden, mit zunehmender Größe und Komplexität ungenauer schätzbar zu sein. Im Zweifel wird stets die höhere Karte gezogen.

Die Einheit, in der geschätzt wird, ist erst mal zweitrangig. Neben einer direkten Schätzung in Mannstunden gibt es auch die Möglichkeit der Schätzung in Storypoints (s.u.). Moderator und/oder Product Owner erklären also nun die zuvor in Userstories oder Teilprobleme zerlegte Anforderung. Die Entwickler dürfen Rückfragen stellen, bis die Anforderung klar verstanden ist.

(ID:43100935)