Artikel versenden

Planning Poker – besser schätzen




 

// /

Die Planungsaktivitäten für das nächste Release des Produkts X laufen auf Hochtouren. Entwicklungsleiter Uwe ist vollauf damit beschäftigt, Aufwandsschätzungen der Entwickler für die einzelnen Features des kommenden Releases zu sammeln. Eines Tages steht er bei mir im Büro: „Frau Roth, wie lange brauchen Sie, um die Funktionalität X umzusetzen“. Ich grüble ein wenig und denke mir, dass ich wohl 8 Tage brauche und schlage noch einen Puffer von 2 Tagen auf. Dann sage ich: „10 Tage“. Darauf Uwe: „Ok, dann sagen wir 5 Tage.“ Er verlässt den Raum, und ich bleibe irritiert zurück und ärgere mich.

Diese oder ähnliche Situationen hat so manch ein Entwickler schon erlebt. Entwicklungsleiter oder andere Verantwortliche laufen über die Flure und sammeln Aufwandsschätzungen von einzelnen Entwicklern, um den Gesamtaufwand für die umzusetzenden Anforderungen zu ermitteln. Testaufwand und was sonst noch so anfällt, wird pauschal addiert. Fertig ist die Schätzung! Ein gegenseitiger Austausch über die Schätzungen seitens des Teams findet häufig nicht statt.

An dieser Stelle setzt das durch Mike Cohn in seinem Buch „Agile Estimating and Planning“ beschriebene Planning Poker an. Es handelt sich dabei um eine konsensbasierte Schätztechnik zur Ermittlung der relativen Größe von Features. Beim Planning Poker setzen sich alle Teammitglieder zusammen, d.h. nicht nur Programmierer, sondern auch Tester, Datenbank-Experten, etc. Auch ein Moderator nimmt teil, um die Features zu präsentieren und die Fragen des Teams zu den einzelnen Features zu beantworten.

Nehmen wir an, dass Monika, Stefan, Torsten und Tanja ein Team sind und am Planning Poker teilnehmen. Die Moderation übernimmt Claus, der als Produkt Manager die Verantwortung für die Features hat. Monika, Stefan, Torsten und Tanja erhalten jetzt jeweils einen Satz von Karten, wobei ein solcher Satz aus den Zahlen 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100 besteht. Die Zahlen stehen dabei für „Story Points“ und stellen die relative Komplexität eines Features dar.

Nun werden die Features der Reihe nach besprochen, also etwa „Ein Nicht-Mitglied kann sich registrieren“. Jedes Team-Mitglied legt verdeckt die Karte hin, welche seiner Meinung nach die relative Komplexität des Features darstellt. Dann werden die Karten umgedreht. Monika und Stefan haben eine 2 geschätzt, Torsten eine 3 und Tanja eine 13. Tanja hält das Feature also für deutlich komplexer als die anderen Teammitglieder. Womöglich hätte sie sich ohne die Karten nicht getraut, eine solch hohe Schätzung abzugeben. Die Argumente für und wider die Komplexität des Features werden ausgetauscht. So ist Tanja der Meinung, dass die Passwort-Verschlüsselung aufwändig sei, was durch Torsten widerlegt wurde, da eine solche Bibliothek schon existiert. Dann wird erneut nach derselben Vorgehensweise geschätzt. Jetzt schätzen alle Team-Mitglieder eine Komplexität von 2 bzw. 3, woraufhin man sich auf die 3 einigt.

Planning Poker liefert bessere Schätzungen als die übliche Vorgehensweise, da die Schätzungen durch ein cross-funktionales Team im Dialog geliefert werden.

 

 

Quelle Foto: © Thomas Pajot – Fotolia.com

| Keine Kommentare

 
Top | Impressum | Datenschutz