Planning Poker in Scrum oder SAFe Meetings

Texas Holdem, Omaha Hi-Low - echte Coder spielen Planning Poker 😎
In diesem Artikel stelle ich vor, wie wir im Rahmen unserer Scrum Zeremonien pokern und gebe euch so einen Einblick in unsere SAFe Refinement Runden.

Einführung

Ich arbeite in einem Scrum-Team, das Teil eines größeren Bereiches ist, in dem es noch viele weitere Scrum-Teams gibt. Mein Bereich Magenta Business organisiert sich nach dem Scaled Agile Framework (SAFe).

Scrum und SAFe

Scrum ist ein Vorgehensmodell zur agilen Softwareentwicklung. Die zu entwickelnde Software wird dabei in Form von User Stories beschrieben. Weitere Infos zu Scrum findet ihr z.B. hier:
https://de.wikipedia.org/wiki/Scrum

SAFe ist ein Framework, das die Zusammenarbeit mehrerer Scrum-Teams organisiert. Dabei macht es Vorgaben, die in Teilen die Freiheitsgrade eines einzelnen Scrum-Teams einschränken. Weitere Infos zu SAFe gibt es hier:

https://www.scaledagileframework.com

Planning Poker

Eine beliebte und gängige Methode zum Schätzen der Umsetzungs-Komplexität einer User Story ist Planning Poker. Beim Planning Poker wird dem Team eine User Story vorgestellt, deren Komplexität im Vergleich zu anderen User Stories dann geschätzt werden soll. Dazu hat jeder Planning Poker Spieler Spielkarten auf der Hand, welche die Zahlen 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 enthalten (grob die Fibonacci Reihenfolge). Mit einer dieser Karten bewertet jeder Spieler dann die Komplexität der vorgestellten User Story.

Planning Poker Karten für einen Spieler

Zum Beispiel schätze ich die User Story "Als Telekom-Fan bin ich begeistert, wenn alle Knöpfe im Geschäftskunden-Portal in der Farbe Magenta sind" mit der Komplexität 5 ein, indem ich verdeckt die Karte 5 spiele. Während ein anderer Kollege die Karte 13 spielt und somit ein mehr als doppelt so große Komplexität erwartet. Das Ergebnis der Planning Poker Runde, also die Schätzung der Komplexität mit einer Karte von jedem Spieler, wird danach solange diskutiert und neue Runden gespielt bis die Spieler sich auf eine Zahl geeinigt hat. Anhand der Velocity (siehe weiterführende Infos zu Scrum) könnte nun berechnet werden, wie viele Komplexitätspunkte das Scrum-Team in einem Sprint schafft.

Weitere Infos zu Planning Poker im Allgemeinen findet ihr hier https://en.wikipedia.org/wiki/Planning_poker oder in den Scrum Büchern, die ich unten verlinke.

☝ Die folgenden Abschnitte sind nur eine Beschreibung, wie wir in Refinement Meetings planen. Es sind keine offiziellen Prozesse oder Regeln, die Teil des Scrum oder SAFe Frameworks sind. Ich lade euch ein, in den Kommentaren zu beschreiben, wie ihr Planning Poker spielt 😀

Probleme beim Refinement und Planning Poker

Planning Poker wird häufig in Refinement Meetings gespielt, in denen die User Stories vorgestellt und diskutiert werden. Das kann unter Umständen ziemlich viel Zeit kosten. Je schlechter die User Story verstanden wird, desto länger wird sie diskutiert und desto schwieriger ist das Schätzen. 

In diesem Artikel werde ich nicht darauf eingehen, wie man gute User Stories schreibt. Mein Schwerpunkt liegt auf der Moderation des Planning Pokers bzw. auf dem Prozess, um zu einem Schätzergebnis zu kommen. Denn auch dieser Teil kann sich ganz schön in die Länge ziehen, insbesondere wenn das Schätzen in Corona-Zeiten digital stattfindet.

Laut Mike Cohn geht es darum, solange Planning Poker zu spielen bis alle Beteiligten einen Konsens gefunden haben. Wenn ich aber als Zwischenergebnis ein große Streuung in den Schätzwerten habe (z.B. wenn folgende Karten von 5 Spielern gespielt wurden: 2, 2, 3, 5, 8), dann ist es sehr wahrscheinlich, dass auch nach der 2. Runde Planning Poker noch kein Konsens gefunden wird. Genau das kostet dann in Telefonkonferenzen besonders viel Zeit, weil jede Meinung bzw. Erklärung der ausgespielten Karte gehört werden soll. Daher haben wir weitere Spielregeln für das Planning Poker abgestimmt, die diese Phase beschleunigen.

Planning Poker Prozess und Moderation

Nachdem die zu schätzende User Story vorgestellt und alle Fragen dazu besprochen wurde, kann die erste Runde Planning Poker gespielt werden. Im Kontext von SAFe gibt es einen wesentlichen Unterschied beim Schätzen im Vergleich zu Scrum:

• Ein einzelnes Scrum Team schätzt einfach nur die Komplexität einer User Story im Vergleich zur Referenz User Story des Teams. Es sollte also keinen Zusammenhang zwischen geschätzten Story Points und Zeit bzw. Aufwand geben.
• SAFe empfiehlt zur Auswahl einer Referenz User Story eine Aufgabe, die möglichst in allen Scrum Teams bekannt ist und die circa einen halben Tag Aufwand benötigt. Diese Referenz User Story bekommt dann den Wert 1. Das wird als Normalisierung der Story Point Schätzungen bezeichnet und sorgt für eine gemeinsame Grundlage, um basierend auf den Schätzergebnissen in den Teams ökonomische Entscheidungen treffen zu können. Alle Details dazu findet ihr hier: 
  https://www.scaledagileframework.com/iteration-planning/
  Also bei SAFe gilt: 1 Story Point ~ 0,5 Tage Aufwand.

Um beim Planning Poker schneller zum Konsens und damit zum Schätzergebnis zu kommen, haben wir Klassifizierungen für die möglichen Ergebnisse einer Runde Planning Poker eingeführt. Jede Klassifizierung hat Regeln, die dem Moderator zeigen, wie er mit dem Ergebnis der Runde umgehen soll. Die nächsten 4 Abschnitte sind unsere 4 Klassen, die alle möglichen Konstellationen beim Planning Poker abdecken (als eingespieltes Team brauchen wir keine Kaffeetassen- und Fragezeichen-Karten).

2 benachbarte Gruppen: Mehrheit mit höherer Schätzkarte oder Pat

Beispiele für diese Klassifizierung sind folgende Kartenverteilungen:

• 3, 3, 5, 5, 5
  5 Karten wurden gespielt, die aber nur 2 verschiedene Schätzwerte enthalten - also 2 Gruppen. Die Gruppen sind benachbart, wenn sie in der Reihenfolge direkt nacheinander kommen, z.B. 1 und 2 sind benachbart oder 8 und 13, da es keine andere Karte mit einem Wert zwischen 8 und 13 gibt. In diesem Beispiel hat die Mehrheit von 3 Spieler den Wert 5 geschätzt.
• 1, 1, 2, 2 ist ein Pat, da 2 Spieler 1 Story Point und 2 Spieler 2 Story Points geschätzt haben.
  
  

  

  Pat-Ergebnis einer Planning Poker Runde 

  
  

Regeln für dieses Schätzergebnis:

1. Keine weitere Diskussion notwendig. 
2. Die zu schätzende User Story bekommt den Story Point Wert der größeren Gruppe.
   (In den Beispielen zu dieser Klassifizierung sind das 5 und 2 Story Points)

Die Regel führt zu einem schnellen Ende des Schätzprozesses und spart dem Team somit Zeit. Aus meiner Sicht bringt weitere Diskussion und Schätzung hier auch nicht viel, weil die zwei benachbarten Gruppen zeigen, dass das Team ein gutes Verständnis von der User Story hat. Im Sinne eines defensiveren Vorgehens runden wir die Aufwandsschätzung auf. Das erhöht die Wahrscheinlichkeit, dass diese Story im Rahmen der geschätzten Komplexität abgearbeitet werden kann.

2 benachbarte Gruppen: Mehrheit für niedrigerer Schätzkarte

Regeln:

• Der Moderator erkundigt sich bei den Spielern mit Karten in höherer Gruppe, warum sie denken, dass es mehr Aufwand ist oder ob sie auch den niedrigere Schätzwert der Mehrheit akzeptieren können.
• Wenn alle Spieler den niedrigeren Story Point Wert akzeptieren, wird dieser für die User Story übernommen. 
• Ansonsten erkundigt sich der Moderator bei mindestens einem Entwickler, warum er als Teil der Mehrheit die kleinere Zahl geschätzt hat und startet dann eine weitere Runde Planning Poker.
  
  

Beispiele:

• 2, 2, 2, 3, 3: Die beiden Spieler mit der Schätzung von 3 Story Points, akzeptieren 2 als Ergebnis für die User Story und die Planning Poker Runde ist beendet.
• 5, 5, 5, 5, 8: Der Entwickler mit der Planning Pokerkarte 8 erklärt, warum aus seiner Sicht zwingend mit einem Aufwand von 8 zu rechnen ist und dass er 5 Punkte nicht akzeptieren kann. Ein weiterer Spieler mit einer Schätzung von 5 Punkten erklärt seine Schätzung. Anschließend startet der Moderator eine neue Runde Planning Poker.
  
  

Mindestens 3 Gruppen oder nicht benachbarte Gruppen

Regeln:

• Jeweils mindestens ein Spieler aus der höchsten und niedrigsten Gruppe erklärt die Gründe für seine Einschätzung.
• Andere Spieler können auch ihre Gründe erklären, da dieses Poker Rundenergebnis erhebliche Unterschiede im Verständnis der User Story zeigt.
• Der Moderator startet eine neue Planning Poker Runde, bei der einige Spieler vermutlich ihre Einschätzung aufgrund der gehörten Begründungen anpassen. 

Beispiele:

• 1, 2, 2, 2, 2, 3: Die Spieler mit den Karten 1 und 3 erklären ihre Gründe, danach startet der Moderator eine neue Runde Planning Poker.
• 1, 3, 3, 3: Hier haben wir zwei nicht benachbarte Gruppen, aufgrund der erheblichen Unterschiede im Verständnis der User Story, sollen die Erklärungen zur Schätzung gehört werden und danach eine neue Runde gespielt werden. Ich empfehle bei diesem Ergebnis nicht einfach der Mehrheit zu folgen, da der Entwickler mit der Schätzung 1 vielleicht eine gute Idee hat, wie man diese User Story einfach und schnell umsetzen kann.
  
  

2. Runde Planning Poker gespielt

Regeln: 

• Im einfachsten Fall haben wir nach der 2. Runde ein Schätzergebnis der Kategorie 2 Gruppen. Dann gelten die zuvor beschriebenen Regeln.
• Schwieriger bzw. langwieriger wird es, wenn wir nach der 2. Runde immer noch in der Kategorie 3 oder mehr Gruppen oder nicht benachbarte Gruppen sind. Dann ist es höchstwahrscheinlich eine kompliziertere User Story, so dass der Moderator diese beiden Möglichkeiten hat:
• Um zu einem Ende zu kommen einigen sich die Spieler auf einen Wert, indem sie einen Kompromiss finden.
• Oder der Moderator zieht die User Story zurück und bereitet sie für das nächste Refinement besser vor, indem er sie splittet oder besser beschreibt. Das sollte auch geschehen, wenn die User Story Schätzergebnisse hat, die besonders groß sind und in der Regel nicht in einem Sprint abgearbeitet werden können.
  
  

Fazit

In diesem Artikel habe ich vorgestellt, wie wir Planning Poker spielen und wo wir von der Lehre abweichen, um schneller zum Ende des Refinement Meetings zu kommen. Mein Ziel war euch einen Einblick in unserer Praxis zu geben. Es geht mir nicht darum Vorgaben zu machen, wie man im agilen Umfeld planen sollte bzw. wie man Planning Poker zu spielen hat. Ich freue mich über Kommentare, wie Planning Poker bei euch in der Praxis abläuft.

Für tiefere Einblicke in Scrum und das Planen in agilen Projekten empfehle ich die beiden Bücher von Mike Cohn.

Buch mit Schwerpunkt auf Schätzen und Planen in agilen Projekten

 

Buch zum Thema agiles Arbeiten mit Scrum