· 

Planning Poker

Ein wichtiger Bestandteil von Scrum besteht darin, die User Stories des Product Backlogs hinsichtlich ihrer Komplexität zu schätzen. Hierzu wird das Planning Poker verwendet. dass nicht nur Spaß macht, sondern auch einfach zu spielen ist und dennoch akkurat genug für die agile Planung.

 

Teilnehmer

Teilnehmer des Planning Poker Spiels sind sowohl der Product Owner (PO) zur Vorstellung der User Stories als auch die an der Fertigstellung beteiligten Entwickler, Designer, Tester etc. Schätzen sollten aber nur aktive Teammitglieder

Zweck PLanning Poker Karten

Für die Schätzung wird eine vereinfachte Fibonacci-Folge herangezogen: 0,1,2,3,5,8,13,20,40,100. Zusätzlich gibt es noch eine Pausenkarte und einer eine Fragenkarte. 

Bei den Zahlen handelt es sich nicht um Aufwände in Tagen, sondern um eine relative Größe, die Story Points genannt wird. Diese gibt die Komplexität einer User Story (aus Benutzersicht) wieder, also den “intellektuellen Aufwand” für die Umsetzung. Schätzwerte unter 3 zeigen beispielsweise an, dass es sich um eine Aufgabe mit geringer Komplexität handelt. Werte über 20 machen deutlich, dass die Komplexität der Aufgabe höher eingestuft wird.

 

Story Points sind somit Aussagen zur Komplexität einer Funktionalität und stellen eine relative Schätzgröße dar. Die Aussagekraft bezieht sich auf den relativen Aufwand im Vergleich zu anderen User Stories. Rückschlüsse auf Manntage oder Stunden ist nicht das primäre Ziel des Schätzvorgehens.

 

 

Ziel

Ziel des Planning Poker Spiels ist es, dass sich jedes Teammitglied aktiv an der Schätzung beteiligt und sein Wissen im jeweiligen Bereich beiträgt. Kann jemand absolut keinen Schätzwert nennen, ist es möglich die Karte mit dem Fragezeichen zu zeigen.

Ablauf

  1. Jeder, der an der Umsetzung des Produktes beteiligt ist, erhält einen Satz Karten.
  2. Nachdem ein Feature durch den Product Owner vorgestellt wurde und alle Fragen beantwortet sind, kann die Schätzung beginnen.
  3. Jeder überlegt im Stillen und Geheimen wie “komplex” die User Story ist und wählt eine Karte aus, die verdeckt vor ihm platziert wird.
  4. Sobald alle Beteiligten gelegt haben, werden die Karten aufgedeckt. Falls es Unterschiede gibt, eröffnet der Scrum Master die Diskussion.
  5. Dazu bittet er die Person mit der höchsten Zahl und die Person mit der niedrigsten Zahl, sich über die Bewertung auszutauschen.
  6. Nach diesen Erkenntnissen einigt sich das Entwicklungsteam auf eine Zahl oder es wird eine zweite Runde eingeführt.

 

 

Das Ergebnis der Schätzung ist besonders für den Product Owner interessant. Gemeinsam mit der Velocity des Teams (Team Geschwindigkeit) erhält er die Möglichkeit, für alle User Stories eine Release Planung durchzuführen.

Kommentar schreiben

Kommentare: 0