Ein kurzer Leitfaden für die Durchführung von Planning Poker
Share
Ein kurzer Leitfaden zum Planning Poker erklärt das Warum, Wie und Was dieser agilen Schätztechnik. In Bezug auf den Scrum-Guide heißt es: „Product Backlog Items haben die Attribute Beschreibung, Reihenfolge, Schätzung und Wert„. Er erklärt jedoch nicht, was „Schätzung“ bedeutet, und überlässt dies den jeweiligen Scrum-Teams auf der ganzen Welt offen und freigestellt. Da klassische Aufwandschätzungen nicht sehr gut funktionieren, verwenden viele Teams Planning Poker zur Erstellung der Schätzungen. Aber, warum machen wir das eigentlich? Wie machen wir das? Was muss beim Einsatz von Planning-Poker beachtet werden? Dieser Artikel gibt einen Überblick und Erläuterungen zu agilen Schätzungen mit Planning Poker.
Inhaltsverzeichnis
Die Ziele und Absichten von Planning Poker
Der Scrum-Guide sagt uns, dass „Product Backlog Items die Attribute einer Beschreibung, Bestellung, Schätzung und Wert haben„. Darüber hinaus „ist die Verfeinerung des Product Backlog der Akt des Hinzufügens von Details, Schätzungen und Aufträgen zu den Elementen des Product Backlog„. Daher ist Planning Poker Teil der Product Backlog-Verfeinerung in Scrum, und sein Hauptziel ist die Schätzung der Product Backlog-Items.
Das Hinzufügen von Schätzungen zu den Product Backlog-Elementen bietet dem Team unterschiedliche Vorteile. Einerseits muss das Team das Product Backlog-Element gründlich diskutieren, um es abschätzen zu können. Dadurch wird ein gemeinsames Verständnis der Anforderung gewonnen. Zweitens schaffen die Schätzungen Transparenz über den Fortschritt und den Status der Verfeinerung von Elementen. Elemente mit einer großen Schätzung müssen weiter verfeinert werden, bevor sie implementiert werden können. Darüber hinaus sind die Schätzungen ein sehr wertvoller Input für die Sprint-Planung. Hier dient die Schätzung als einer der Schlüsselparameter für die tatsächliche Planung, wobei der Umfang der geplanten Arbeit niemals die Kapazität des Teams überschreiten sollte.
Das Setup von Planning Poker
Schauen wir uns zunächst an, wie eine Runde Planning Poker aufgebaut ist. Wer nimmt teil und welche Utensilien werden benötigt? Wie bereits erläutert, ist die Schätzung von Product Backlog-Einträgen Teil des Refinements. Laut Scrum Guide ist die Verfeinerung ein „kontinuierlicher Prozess, in dem der Product Owner und das Development Team gemeinsam die Product-Backlog-Einträge detaillieren". Umgekehrt bedeutet dies, dass mindestens der Product Owner und das Entwicklungsteam für ein Refinement Meeting erforderlich sind. In vielen Teams nimmt der Scrum Master jedoch auch als Moderator oder Zeitnehmer am Refinement teil. Zum Beispiel kann er verhindern, dass die Diskussion abschweift, oder die Einhaltung des zeitlichen Rahmens überwachen.
Ein weiterer Aspekt, der im Scrum Guide definiert ist, ist das Timing und der Zeitaufwand, der in Planning Poker investiert werden kann. „Das Scrum Team bestimmt, wann und wie diese Verfeinerungsarbeit erfolgt. Sie sollte normalerweise nicht mehr als 10% der Kapazität des Development Teams beanspruchen". Da sich das Team auf einen gemeinsamen Ort und Zeitpunkt für die Umsetzung einigen muss, sollten diese natürlich entsprechend reserviert werden. Der Scrum Master behält auch den Umfang der Refinement Meetings im Auge. Wenn diese regelmäßig die 10% eines Sprints überschreiten, sollte dies in der Sprint-Retrospektive behandelt und eine entsprechende Lösung ausgearbeitet werden.
Wenn sich die Teammitglieder zum Refinement versammelt haben, werden die Planning Poker-Karten verteilt. Der Scrum Guide gibt an, welche Teammitglieder schätzen dürfen. „Die endgültige Schätzung erfolgt immer von denen, die auch die Arbeit erledigen werden". Dies bedeutet, dass nur Mitglieder, die möglicherweise für die Implementierung eines Product Backlog-Elements berechtigt sind, eine Schätzung vornehmen dürfen. Sie erhalten jeweils einen Satz Planning Poker-Karten. Diese bestehen aus zehn Karten mit Punktwerten und drei Spezialkarten. Schauen wir uns zunächst diese Karten selbst an, bevor wir uns den Ablauf von Planning Poker ansehen.
Story Points als Waffe der Wahl
Da klassische Aufwandschätzungen nicht gut funktionieren, müssen wir eine andere Methode finden, um Schätzungen für Elemente des Product Backlog zu erstellen. Im Idealfall können wir mit dieser Technik nicht nur den Aufwand für die Bearbeitung des Product-Backlog-Elements abdecken, sondern auch Risiken und Unsicherheiten berücksichtigen. Mit anderen Worten, wir wollen die Komplexität eines Product-Backlog-Elements schätzen und nicht nur seinen Aufwand.
Hier kommen Story Points ins Spiel. Story Points sind Zahlen, die aus Fibonaccis Sequenz abgeleitet wurden. Sie ermöglichen es uns, alle oben genannten Kriterien in unsere Schätzungen einzubeziehen. Daher zeigen Planning Poker-Karten Story Points als Schätzwerte an. Die verfügbaren Story Point-Werte sind 0, 1, 2, 3, 5, 13, 20, 40 und 100. Darüber hinaus sind spezielle Karten, z.B. für eine Kaffeepause, in den Kartensätzen enthalten.
Die Durchführung von Planning Poker
Wir haben bereits gesehen, dass Planning Poker nur ein Teil des Refinement ist. Es ist daher sinnvoll zu prüfen, welche Schritte die Verfeinerung eines Product Backlog-Elements durchläuft.
Zuerst stellt der Product Owner dem Entwicklungsteam die Anforderung vor. Er erklärt den Kontext, den Inhalt, stellt die zugehörigen Mock Ups und den Mehrwert für den Kunden vor. Dann werden die Anforderungen und die möglichen Lösungen zwischen dem Product Owner und dem Entwicklungsteam im Detail besprochen. Hier werden Entscheidungen über die System- und Software-Architektur getroffen. Ein Eintrag kann nur abgeschätzt werden, wenn der Implementierungspfad klar ist.
Wenn es keine weiteren Fragen zur Funktionalität und der gesuchten Lösung gibt, initiiert der Moderator die Abschätzung, d.h. den Planning Poker selbst. Er bittet die Teilnehmer, die Pokerkarte mit dem entsprechenden Wert aus ihrem Kartensatz auszuwählen. Alle Karten sind verdeckt und für die anderen Teammitglieder noch nicht sichtbar.
Der Moderator bittet die Teilnehmer, gleichzeitig ihre Schätzwerte anzuzeigen, d.h. die Karten umzudrehen. Es ist wichtig, dass es den Teilnehmern nicht erlaubt ist, ihre Schätzung zu korrigieren, nachdem sie die Schätzung eines Teammitglieds gesehen haben. Nun kann es zwei Situationen geben. Möglicherweise gibt es einen Konsens über die Schätzung. In diesem Fall wird die Schätzung dem Product Backlog-Element hinzugefügt.
In den meisten Fällen weichen die Schätzungen der Teammitglieder jedoch voneinander ab. In diesem Fall erklären die jeweiligen Entwickler, warum sie so geschätzt haben. Sobald sie die Diskussion beendet haben, wird der Gegenstand erneut geschätzt. Dies wird so lange fortgesetzt, bis ein Konsens erzielt wurde. Dies kann natürlich sehr lange dauern. Es gibt einen eleganten Weg, diese Diskussionen zu verkürzen und dennoch zu einem aussagekräftigen Ergebnis zu kommen.
Wenn die Schätzungen der Teammitglieder nur eine Größenordnung auseinander liegen, wird ohne Diskussion der höhere Wert als Schätzung verwendet. Offenbar sieht mindestens ein Teammitglied ein erhöhtes Risiko, einen erhöhten Aufwand oder eine erhöhte Unsicherheit. Indem das Team die höhere Schätzung akzeptiert, respektiert es dieses potenzielle Risiko und gleicht es nicht aus. Dadurch wird das Risiko einer Unterschätzung verringert.
Die Einführung von Planning Poker in Teams
Abschließend wollen wir einen Blick darauf werfen, wie Planning Poker in Scrum-Teams eingeführt werden kann. Normalerweise ist es ausreichend, Planning Poker mit einem neuen Team ohne große Vorbereitung zu spielen. In der ersten Runde sollten dem Team die Regeln erklärt werden. Aufgrund der ungewöhnlichen Art der Story-Punkte sollte jedes Team auch eine „Baseline-Story“ definieren. Dies sollte die einfachste Aufgabe sein, die jedes Teammitglied erledigen kann, und dies ist der Vertreter eines einzelnen Story Points. Alle anderen Geschichten beziehen sich auf diese Grundaufgabe. Während der ersten Pokerrunde kann der Scrum Master das Team als Mentor unterstützen.
Es gibt kein Richtig oder Falsch bei der Einschätzung von Story Points. Das Einzige, was ein Team anstreben sollte, ist Konsistenz. Alle Schätzungen sollten so konsistent wie möglich sein. Zu Beginn wird das Team einige Schwierigkeiten haben, eher die Komplexität als den Aufwand abzuschätzen. Mit der Zeit wird sich jedoch die Fähigkeit des Teams, gute Schätzungen vorzunehmen, verbessern.
Es ist möglich, Neulingen beim Planning Poker visuell zu helfen, indem man entsprechende Spielkarten verwendet. Für einen Scrum Master kann dies auch das Coaching eines Teams in agilen Schätztechniken wesentlich erleichtern. Gleichzeitig werden die geschätzten Punktzahlen viel konsistenter. Dies sorgt für eine stabilere Velocity und erleichtert damit auch die Sprintplanung. Spielerisch gestaltete Karten sind ideal, um Scrum in Entwicklungsteams einzuführen.
Abschließende Gedanken
In diesem Artikel haben wir einen kurzen Einblick in die Welt der agilen Schätzung mit Planning Poker gegeben. Wir haben die Einrichtung und Durchführung von Planning-Poker-Runden besprochen. Wir sprachen auch über das Warum und Was von Story Points und ihre Fähigkeit, Risiken und Unsicherheiten in unseren Schätzungen abzudecken.
Teams, die neu in Planning Poker eingeführt wurden, können durch die Verwendung anschaulicher Pokerkarten unterstützt werden. Diese geben eine grafische Darstellung des dargestellten Story-Point-Wertes statt nur der einfachen Zahl. Teams brauchen die Einführung von Planning Poker nicht zu fürchten, solange einige einfache Regeln befolgt werden. Eine der Grundregeln ist die Konsistenz der vom Team vorgenommenen Schätzungen. Ein kurzer Leitfaden für die Durchführung von Planning Poker kann als schnelle Referenz für Trainer, Teams und Manager in der agilen Gemeinschaft verwendet werden.
