Da Scrum nur ein Rahmenwerk ist, wie Projekte abgewickelt werden sollen, hält es sich bei der konkreten Implementierung zurück, solange die Eckpfeiler (Rollen, Regeln und Time-Boxen) eingehalten werden. So ist Planning Poker kein fester Bestandteil von Scrum, aber durchaus Best Practice.

Zu Beginn eines Sprints werden im “Planning Meeting 1″ die Features, die in der Iteration umgesetzt werden sollen, besprochen und geschätzt. Der Product Owner gibt mit seiner Priorisierung die Wichtigkeit der Features vor. Weiterhin Best Practice ist, die Features in Form von User Stories zu verpacken, weil diese für den Techniker wie den Product Owner gleichermaßen verständlich sind. Wie viele User Stories in ein Sprint gepackt werden, hängt von der Aufwandsschätzung ab und damit sind wir mitten im Planning Poker.

Planning Poker ist ein spielerisches und konsensorientiertes Verfahren, um auf eine realistische Schätzung des Entwicklungsaufwands eines Features oder einer User Story zu kommen. Man benötigt dazu ein Kartenspiel mit speziellem Kartenwerten. Jeder im Entwicklungsteam erhält einen Satz, der die Karten: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, “?” und “Pause” umfasst.

Der Scrum Master moderiert das Planning Poker und man einigt sich zu Beginn auf eine einfache User Story (etwa: „Ermögliche dem Besucher eine einfache Kontaktaufnahme mit dem Webseitenbetreiber über ein entsprechendes Formular“), die den Wert 2 bekommt. Der Product Owner stellt daraufhin die konkrete User Story vor und beschreibt nochmals, was sie umfasst. Dabei ist wichtig, dass der Product Owner eine Wertung wie „leicht“, „aufwändig“ oder „schnell umzusetzen“ auf jeden Fall vermeidet, um eine Voreingenommenheit des Teams zu vermeiden.

Daraufhin schätzen die Spieler für sich den Aufwand der gegeben User Story relativ zu dem mit 2 bewerteten Feature und legen alle gleichzeitig die Karte mit dem geschätzten Aufwand offen. Die beiden Spieler, die den jeweils höchsten und niedrigsten Wert geschätzt haben, müssen den anderen nun erklären, wie sie zu der Entscheidung kommen und die Schätzung begründen. Daraufhin wird das Prozedere wiederholt, bis sich ein Konsens unter den Spielern bildet. Lässt sich auch nach mehreren Durchgängen kein Konsens finden, bekommt der Entwickler, der die User Story am ehesten umsetzen wird mehr Gewicht oder man greift zu einem der konservativen Werte, um auf Nummer sicher zu gehen.

Für was die Werte auf den Karten stehen, wird zuvor festgelegt. Das können konkrete Manntage sein, es können aber genauso gut abstrakte Story Points sein, die einfach den Aufwand in Sachen Komplexität beschreiben ohne dabei eine Aussage zum Zeitaufwand zu treffen. Was ein Story Point in tatsächlich zeitlichem Aufwand bedeutet, wird sich erst nach einigen Sprints zeigen können. Das abstrakte Verfahren hat den Vorteil, dass die Schätzung in Relation zur Komplexität eines anderen geschieht und nicht immer der Gedanke an eine konkrete Zeit im Vordergrund steht.

Hat das Scrum Team alle im Sprint zu entwickelnden User Stories nach diesem Verfahren geschätzt, geht es dann im “Planning Meeting 2″ darum, aus den gewählten User Stories konkrete Entwicklungstasks zu erstellen, die das so genannte Sprint Backlog darstellen. Als Faustregel gilt dabei, dass ein Task so klein wie möglich und in maximal einem Tag zu realisieren sein soll.

Das Planning Poker hat einige Vorteile gegenüber anderen Schätzverfahren und es passt hervorragend in ein Scrum-Projekt:

• Es gibt keinen Projektleiter, der vorgibt, wie lange etwas zu dauern hat. Das Entwicklungsteam ist autonom in seiner Schätzung.
• Es werden alle Entwickler gleichberechtigt befragt und die Entscheidung fällt im Konsens.
• Mit dem Verfahren kann man sowohl konservative wie progressive Schätzer-Typen einfangen und an einen Tisch holen.
• Die Wiederholung des Planning Poker zu Beginn eines jeden Sprints sorgt für eine Optimierung des Schätzens und damit einer Erhöhung der Zuverlässigkeit des Teams.
• Der Scrum Master moderiert das Verfahren, weist auf die Verbesserungen zwischen den einzelnen Sprints hin und erhöht das Selbstvertrauen des Teams in die eigenen Fähigkeiten.

Teams, die Planning Poker noch nicht kennen, sollten es unbedingt einmal ausprobieren. Es lockert nicht nur das nervige Schätzen durch spielerische Elemente auf, sondern es löst tatsächlich Probleme. Planning Poker Karten gibt es bei spezialisierten Händlern zu kaufen oder man lässt sich sein Kartenspiel von entsprechenden Dienstleistern individuell drucken – etwa im firmeneigenen Erscheinungsbild.

Dabei ist Scrum zunächst “nur” ein teambasierendes Framework, das auf nur wenigen Rollen, Regeln und Time-Boxen basiert. Ich werde in diesem Beitrag nicht umfänglich auf das gesamte Framework eingehen, das kann man hier gut nachlesen. Ich werde mich vorwiegend auf die Bedeutung für das Entwicklungsteam beschränken. Bei Bedarf bzw. Nachfrage stelle ich aber auch gerne einmal das gesamte Framework in einem gesonderten Beitrag vor.

Ziel bei einer Projektabwicklung mit Scrum ist es, eine deutlich höhere Produktivität und Kundenzufriedenheit zu garantieren, weil durch den ständigen Dialog mit dem Interessenvertreter von Kundenseite (Product Owner) und den kurzen Iterationen (Sprints mit garantierter Auslieferung von lauffähigen Produktinkrementen) eine höchste Übereinstimmung zwischen Entwicklungsauftrag und Ergebnis gewährleistet wird.

Nimmt man das gesamte Scrum Team, so finden sich dort drei Rollen wieder:

• Der Product Owner als Vertreter des Kunden, der vorwiegend die Anforderungen und Produkteigenschaften einbringt und am wirtschaftlichen Erfolg des Projekts gemessen wird.
• Der Scrum Master, der als “Kümmerer” zwischen Product Owner und Entwicklungsteam vermittelt und dafür sorgt, dass der Scrum Prozess eingehalten wird. Sein Erfolg wird an der Produktivität des Entwicklungsteams gemessen.
• Und schließlich das Entwicklungsteam, dessen Aufgabe es ist, am Ende eines Sprints, der zwei oder vier Wochen dauert, ein lauffähiges Produktinkrement zu liefern und daran auch gemessen wird. Am Ende des Produktionszyklus soll dann natürlich auch das fertige Produkt ausgeliefert sein.

Bei Scrum managt und organisiert sich das Entwicklungsteam selbst. Das liegt daran, dass die Verantwortung für die Fertigstellung des Inkrements oder Produkts in der Hand des Entwicklungsteams selbst liegt. Die Mitglieder des Entwicklungsteams entscheiden idealerweise selbst, welche Tasks sie abarbeiten. Der Scrum Master leitet nur zu dieser Selbstorganisation an, er ist nicht der Projektmanager im herkömmlichen Verständnis – den gibt es bei Scrum nicht. Weiterhin ist das Entwicklungsteam interdisziplinär besetzt und umfasst das gesamte Wissen und die Fähigkeiten, die für das Projekt nötig sind. Es finden sich also nicht nur Entwickler sondern ebenso auch Architekten, Tester etc. im Team. Ein Entwicklungsteam umfasst zwischen fünf und neun Mitgliedern, idealerweise sieben.

Damit verbunden ist auch eine hohe Transparenz und Ehrlichkeit des Entwicklungsteams zum Product Owner, zum Scrum Master und auch untereinander. Das Entwicklungsteam muss ein wirkliches Team werden, Ablehnung von Code Reviews oder der Rückzug ins stille Kämmerlein sind No-Gos mit Scrum. Probleme bei der Entwicklung müssen an Scrum Master sowie Product Owner in aller Offenheit weitergegeben werden. Im Gegenzug dazu erhält das Entwicklungsteam die uneingeschränkte Unterstützung der Organisation und des Kunden. Das bezieht sich auch auf die eingesetzten Techniken: Tests, Continuous Integration, Code Reviews und Versionskontrolle sind Pflicht, selbst wenn sie vom Scrum Framework nicht explizit genannt werden.

Generell gesprochen ist Scrum ein Framework, das vor allem auf Kommunikation basiert. In allen vorgeschrieben Meetings (Planungsmeetings, Sprint-Review-Meeting, etc.) kommunizieren die Mitglieder des Scrum Teams miteinander. Auch beim Daily Scrum, zu dem sich alle Mitglieder des Entwicklungsteams täglich für 15 Minuten mit dem Scrum Master treffen, um über Fortschritte und Probleme im Projekt zu berichten, steht der gegenseitige Austausch im Mittelpunkt.

Wie man schnell sieht, erfordert Scrum von einem Entwicklungsteam eine ganze Menge – Dinge, die man nicht immer voraussetzen kann, sondern die zumeist erst erlernt und eingeübt werden müssen. Das geht nicht über Nacht, sondern die Einführung von Scrum in einem Unternehmen kann sich über Monate hinziehen. Hier ist der Scrum Master gefragt, der das Team immer wieder ermuntert, anleitet, ihm zur Seite steht und Hindernisse für das Team auf jeder Ebene aus dem Weg räumt. Die Einführung von Scrum lohnt sich aber dennoch, denn der Gewinn an Produktivität und Kundenzufriedenheit ist den Aufwand in jedem Fall wert.