Projekt-Praktikum: Karten-Nachschlag (Update)

Bärbel de BouvierUpdate: Wer sagt denn, dass man im Internet nichts lernen würde? Kommentator Markus Hippeli macht darauf aufmerksam, dass ich bei der Aufwandsschätzung einem Mißverständnis aufgesessen bin. Mehr dazu in seinem Kommentar unter diesem Beitrag. Danke für diesen Hinweis (und sorry Chef!). Ich habe die entsprechenden Passagen nun geändert.

Im letzten Beitrag habe ich kurz das Thema Zeitplanung in Scrum-Projekten mittels eines Kartenspiels angesprochen. Die Frage ist natürlich, warum die Zeitplanung per Kartenspiel besser funktionieren sollte, als ohne. Die Antwort ist ganz einfach: Die Schätzungen werden genauer!

In einer perfekten Welt mit perfekten Menschen wären solche Karten natürlich nicht notwendig. Aber Menschen sind halt Menschen und deshalb brauchen sie Hilfsmittel, die eine Diskussion zum einen schnell auf den Punkt bringen, zum anderen jeden dazu zwingen mitzumachen und über ein gegebenes Thema mit gegebener Ernsthaftigkeit nachzudenken. Für die Aufwandsschätzung in agilen Projekten helfen eben die Planning-Poker-Karten. Und so funktioniert es:

Im Sprint-Planning-Meeting stellt der Product-Owner die einzuschätzende User-Story vor. Danach zückt jedes Team-Mitglied die Karte, deren Wert seiner Meinung nach dem entsprechenden Aufwand entspricht. Ist also ein Team-Mitglied der Meinung, die Userstory erfordert einen Aufwand von „5“, zückt er die entsprechende Karte.

Sind die Karten alle identisch, ist alles klar. Liegen die Werte nahe beieinander, also beispielsweise dreimal die „5“ und zweimal die „8“, gewinnt die Mehrheit.

Interessant wird es, wenn die Werte weit auseinander liegen oder es mehr als zwei Werte gibt. Also wenn beispielsweise einmal die „3“, dreimal die „5“ und einmal die „8“ gezogen werden. Dann ist klar, und nur dann, dass es Diskussionsbedarf gibt. Nun müssen die beiden „Extremwerte“ erklären, warum sie der Meinung sind, dass die Aufgabe nur so kurz, beziehungsweise so lang benötigt. Die Gründe können vielfältig sein. Beispielsweise, weil der Kenntnisstand der Team-Mitglieder unterschiedlich ist, weil der Product-Owner die User-Story nicht richtig erklärt hat oder weil allgemein nicht alle Fakten zu einer User-Story bekannt sind.

Nachdem der Fall durchdiskutiert beziehungsweise nachrecherchiert ist, wird nochmals abgestimmt.

Im Endergebnis erzielt man mit dem Planning-Poker genauere Schätzungen, spart Zeit, weil das Spiel dazu erzieht nur die Dinge zu Diskutieren über die Unklarheit (stark unterschiedliche Aufwandsschätzungen) herrscht und vor allem führt es im Rahmen eines Erziehungsprozesses zu besseren, weil genauer spezifizierten User-Stories.

3 Gedanken zu „Projekt-Praktikum: Karten-Nachschlag (Update)

  1. Ganz böses Missverständnis! Mit den Pokerkarten wird mitnichten der Aufwand geschätzt sondern die Komplexität – das ist ein himmelweiter Unterschied. Auf keinen Fall entsprechen die Zahlen auf den Karten Aufwand im Sinne von Manntagen oder -stunden – davon (von dieser trügerischen Sicherheit) gerade wegzukommen und einen Metamasstab „Komplexität“ einzuführen ist das Ziel der Karten. Die Zahlen basieren auf dem Urmeter, das jedes Team zu Beginn seiner Scrumkarriere festlegt. Hierbei handelt es sich typischerweise um eine Story, die alle im Team gleichermassen gut einschätzen können. Die Zahlen sind in erster Linie für den Productowner wichtig – darauf basierend kann er seine Priorisierung und Releaseplanung machen. Ferner kann er erkennen, ob er seine Stories passend geschnitten und formuliert hat – idR sollten bei Zahlen über 20 die Warnlampen angehen (für die üblichen Karten von 1-100 bei üblichen Teamgrössen und geeignetem Urmeter). Aufgrund der Kartenwerte als annähnernde Fibonaccifolge ergibt sich automatisch, dass kleinere Zahlen eine genauere Schätzung liefern und deshalb erstrebenswert sind. Für das Sprintplanning des Teams sind diese Zahlen komplett unwichtig – sie kommen erst wieder beim Burndownchart zum Einsatz und bei der Velocityberechnung des Teams.
    Die hier im Blog geäusserte Einschätzung der Storypoints ist leider ein verbreitetes Missverständnis – richtiger wird es dadurch nicht! Viel Spass weiterhin beim EInarbeiten in Scrum 😉

  2. Pingback: Projekt-Praktikum: Aufwandsschätzung » MacPM.net

Kommentare sind geschlossen.