Digitale Kultur

Planning Poker – Vegas Baby!

Immer wieder komme ich in agil arbeitende Teams, in denen es zu Beginn nicht ganz klar ist, wie man im agilen Kontext planen kann. Viele denken noch in klassischen Methoden und können sich eine Schätzung ohne „messbare Einheiten“ wie Zeit oder Personentage nicht richtig vorstellen. Ein Vorgehen, dass sich gut bewährt hat, ist Planning Poker.

Aber warum schätzen wir agil?

Einer der großen Vorteile von agilen Schätzmethoden ist, dass damit wunderbar Diskussionen über Anforderungen angefacht werden können. Somit bekommt das Team ein einheitliches Verständnis, da unterschiedliche Blickwinkel beleuchtet werden. Es ist im Grunde genommen egal, welches agile Schätzverfahren angewendet wird, da es um das Bündeln der Erfahrungen der Entwickler geht, woraus sich wiederum eine bessere Schätzung ergibt. Hierbei gibt es kein richtig oder falsch. So kann das eine Team die Story auf 5 und ein anderes Team auf 8 Story Points schätzen. Jedes Team hat ein eigenes Verständnis von der Komplexität der Story Points. Story Points sind bewusst abstrakt, damit jedes Team seinen eigenen Bezug dazu entwickeln kann. Mittels des Feilschens um Punkte stellt das Team ein einheitliches Verständnis und Wissen her. Damit wird eine geteilte Verantwortung erreicht, da das ganze Team an der Entscheidungsfindung beteiligt war!

Warum ausgerechnet schätzen mit Komplexität?

Stellen wir uns mal vor, wir als guter Läufer benötigen 30 Minuten für 5 Kilometer, unser Kollege hingegen 60 Minuten für die gleiche Strecke. Wir wollen zusammen laufen gehen, ein Kompromiss wäre die Strecke in 45 Minuten zu laufen. Für uns ist es zu langsam und für den Kollegen zu schnell. Versuchen wir mit Zeit einen Kompromiss zu finden, gibt es keine optimale Lösung. Wenn man eine abstrakte Messmethode verwendet, wird man sich schnell einig, dass der Weg fünf Kilometer beträgt. Die Dauer und Geschwindigkeit sind hierbei irrelevant, jeder darf sein eigenes Tempo laufen bei gleichbleibender Strecke. Bei Entwicklern ist es ähnlich – der eine benötigt einen Tag, ein anderer zwei Tage für die gleiche Aufgabe. Dennoch sind sich alle einig, der Läufer für die Strecke und der Entwickler für die Story, dass das Ziel dasselbe ist, jedoch jeder eine unterschiedliche Dauer benötigt.

Schätzen, aber wie?

Aber wie schätze ich denn nun anhand von Komplexität? Eine gängige Methode zum spielerischen Schätzen von Komplexität ist Planning Poker. Sie wird sehr oft in Entwicklungsteams genutzt, um einen gemeinsamen Konsens zu generieren. Vorzugsweise macht eine Schätzung in homogenen Teams am meisten Sinn, da jedes Teammitglied ähnliche Fähigkeiten aufweist. Hierbei gilt, jeder der in die Entwicklung des Projektes involviert ist, nimmt am Planning Poker teil. „Jeder“ impliziert hierbei nicht nur die Entwickler, sondern beispielsweise auch Analysten, Database-Engineers oder Tester. Die Auftraggeber, Designer, Product Owner oder Projektleitung schätzen nicht, da diese in der Regel nicht an der Entwicklung der Stories beteiligt sind.

Jeder Teilnehmer erhält einen Satz von Karten (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pause). Die Punktwerte entsprechen dem relativen Arbeitsaufwand und werden als Story Points bezeichnet. Das Fragezeichen kann ein Teammitglied wählen, wenn dieser sich sehr unsicher ist oder auf Grund von fehlender Fachexpertise keine Schätzung erbringen will. Die „Pause“-Karte kann jederzeit ausgespielt werden. Diese wird geworfen, wenn das Team mental nicht mehr ganz bei der Sache ist und eine 5-10-minütige Pause benötigt. Das generelle Vorgehen beim Planning Poker ist wie folgt:

  1. Der Product Owner oder der Projektleiter stellen die zu schätzende Aufgabe vor
  2. Das Team stellt Fragen und macht Vorschläge, sodass die Aufgabe ggf. angepasst werden kann
  3. Teammitglieder schätzen die Aufgabe anhand ihrer Erfahrungswerte, indem sie eine Karte verdeckt auf den Tisch legen
  4. Liegen alle Karten verdeckt auf dem Tisch, drehen alle gleichzeitig ihre Karte um
  5. Sind Abweichungen vorhanden, begründet jeweils das Teammitglied mit der niedrigsten und der höchsten Karte ihre Wahl
  6. Anschließend findet in der Regel eine Diskussion und eine weitere Schätzung statt
  7. Die Zyklen der Schätzung und Diskussion können beliebig oft wiederholt werden bis das Team zu einem Konsens kommt. Die Stimme des Teilnehmers, welcher die Aufgabe umsetzt, hat die höchste Gewichtung. Kommt es zu keiner Einigung, wird die Schätzung vertagt und zur nächsten Aufgabe übergegangen.

Paint the Room

Die Theorie hinter dem Schätzen mit Komplexität verstehen die meisten recht schnell. Jedoch ist es nicht ganz so einfach, den Teammitgliedern ein „Gefühl“ für das Schätzen zu vermitteln. Ein effektives Spiel, welches meine Coaching-Kollegen und ich hierfür gerne beim Kunden anwenden, ist Paint the Room.

Hierbei wird dem Team die Aufgabe gegeben den Raum zu streichen, in dem es sich gerade befindet. Im Spiel ist der Produktmanager/Kunde gleich der Spielleiter, dieser hat die Aufgabe die Fragen des Teams zu beantworten. Als Coaches nehmen wir die Rolle des Kunden/Produktmanagers ein und formulieren eine vage Anforderung mit „Bitte streichen Sie den Raum“. Vorab haben wir im Backlog Items mit spezifischen Namen für jede Wand erstellt. Diese sehen folgendermaßen aus:

  •       streichen Sie die Nordwand
  •       streichen Sie die Südwand
  •       streichen Sie die Ostwand
  •       streichen Sie die Westwand
  •       streichen Sie die Decke
  •       streichen Sie den Boden

Um einen Anhaltspunkt für das Team zu liefern, wird eine Referenzwand festgelegt. Hierbei sucht der Spielleiter sich eine Wand mit mittlerem Arbeitsaufwand heraus und legt diesen auf 5 Story Points fest. Auf Basis dessen muss das Team mittels Planning Poker die anderen Wände schätzen. Nach jeder Schätzung wird diskutiert, weshalb wer wie geschätzt hat. Um ein besseres Gefühl dafür zu bekommen, wie die Methode bei Teilnehmern ankommt, habe ich eine kleine Umfrage unter meinen Kollegen durchgeführt.

Wie war dein Eindruck, wie das Spiel bei den Teilnehmern ankam?

Carsten: Sehr positiv. Ich bin immer wieder überrascht, wie schnell die Beteiligten in Diskussionen einsteigen und welche Begeisterung durch das Spiel entfacht wird. Oftmals gehen die Diskussionen auf einer tieferen Ebene ins Detail, was man zu Beginn erst einmal nicht erwartet, da es ja „nur“ um das Streichen einer Wand geht.

Konnten die Teilnehmer danach besser Stories schätzen und haben sie das Prinzip verstanden?

Ingo: Die Teilnehmer haben besser verstanden, dass das Schätzen nur ein Vehikel ist, um einen gemeinsamen Wissensstand herzustellen. Das eigentlich Interessante sind die Diskussionen, in denen unterschiedliche Blickwinkel beleuchtet werden. So hatte beispielsweise ein Mitglied beachtet, dass das Regal vor dem Streichen aus dem Weg geräumt werden müsse oder der andere, dass die Steckdosen abgeklebt werden müssten.

Was sind generelle Herausforderungen in der Methode?

Fabian: Eine Herausforderung ist die Anmoderation, da man die Leute mit der Aussage: „Wir spielen jetzt ein Spiel“ nicht abschrecken möchte. Gerade dann, wenn die Teilnehmer dich noch nicht kennen, werde ich hier sonst auch mal schräg angeschaut. Ein weiterer Punkt ist das Anleiten oder das Lösen von Konflikten in den Diskussionen, da die unterschiedlichen Sichtweisen in Einklang gebracht werden müssen. Nicht zuletzt ist es auch wichtig, die Teilnehmer zu motivieren, sodass sich wirklich jeder einbringt und mit diskutiert.

Geteiltes Leid ist halbes Leid!

Neben dem Planning Poker gibt es noch weitere Methoden, um Komplexität in einem Projekt zu schätzen. Dazu gehören beispielsweise T-Shirt Größen, Zoo, Farben oder auch NoEsimate. Bei NoEsimate findet im Gegensatz zu den anderen Methoden keine Schätzung statt. Hier wird versucht große Stories zu schneiden, sodass alle Stories die gleiche Komplexität haben und die Zeit beim Schätzen eingespart wird. In der Regel sucht sich das Team selbst das Verfahren aus, welches ihm am besten liegt.

Generell sind agile Schätzmethoden eine Technik, um unterschiedliche Sichten und Meinungen einzelner Personen im Team aufzudecken. Dadurch werden Diskussionen angeregt und Unklarheiten beseitigt, womit eine optimalere Lösung und ein gemeinsames Verständnis geschaffen wird. Somit ist jedem Entwickler klar, was er im jeweiligen Sprint zu tun hat. Mittels der agilen Schätzmethoden werden außerdem die unterschiedlichen Geschwindigkeiten der Entwickler berücksichtigt, da lediglich das Ziel klar gesteckt ist. Die Dauer, welche ein Entwickler für ein Item benötigt, ist somit nicht festgelegt.

Zu guter Letzt würde ich gerne Eure Meinung zu agilen Schätzmethoden wissen? Schreibt mir doch einfach auf Twitter!