Scrum - Einführung in der Unternehmenspraxis || Methoden
3
18 Methoden 18.1 Planning Poker Planning Poker 1 ist eine Methode, um Aufwände relativ zu schätzen. Jedes Teammitglied bekommt dazu einen Satz Spielkarten, die mit den Zahlen 1, 2, 3, 5, 8, 13 und 21 bedruckt sind (viele Kartensätze enthalten außerdem noch die Werte 0, 40, 100 und ?, wobei das „?“ für „Ich habe eine Frage, die eine Schätzung verhindert“ steht). Die Schätzungen der Vergangenheit stellen im weiteren Verlauf die Referenz dar, zu der man relativ schätzt (hat man noch nichts geschätzt, definiert man willkürlich das scheinbar kleinste Element als „3“). Der Product Owner stellt dann ein Product Backlog Item vor, die Teammitglieder stel- len Fragen. Schließlich wird geschätzt, indem jedes Teammitglied eine Karte verdeckt vor sich hält und alle gleichzeitig umgedreht werden. Die Personen, die den höchsten und den niedrigsten Schätzwert abgegeben haben, begründen, warum sie der jeweiligen Meinung sind. Diskussionen werden vom Scrum Master kurz gehalten. Fachliche Klärungen wer- den vom Product Owner unterstützt. Sind die Meinungen ausgetauscht, bildet sich jeder seine Meinung neu und schätzt erneut. Wenn nach drei Durchgängen kein Konsens er- reicht ist, wird im Regelfall der höchste Wert genommen. In Einzelfällen (stark vom Team abhängig), kann auch die häufigste Nennung gewählt werden. Auf diese Weise erhält man keine absoluten Schätzungen in Zeit (also zum Beispiel „3 Personentage“), sondern rela- tive Schätzungen. Man weiß also nur, dass eine „13“ fast dreimal soviel Aufwand ist, wie eine „5“. Erst in Verbindung mit der spezifischen Team-Velocity ergibt sich eine Aussa- ge darüber, wie lange eine „5“ wirklich dauert. Der große Vorteil dieser Methode ist, dass sie nicht nur sehr schnell anzuwenden ist, sondern auch bei Veränderungen des Umfelds (Personen wechseln das Team, das Team lernt dazu und wird schneller, vorher unbekann- te Probleme tauchen auf, alte Probleme sind plötzlich gelöst ...) nicht jedes Element neu geschätzt werden muss, sondern sich nur die Velocity verändert – die relative Größe der 1 Planning Poker® ist ein registriertes Warenzeichen von Mountain Goat Soſtware, LLC. 185 D. Maximini, Scrum - Einführung in der Unternehmenspraxis, DOI 10.1007/978-3-642-34823-5_18, © Springer-Verlag Berlin Heidelberg 2013
Transcript of Scrum - Einführung in der Unternehmenspraxis || Methoden
18Methoden
18.1 Planning Poker
Planning Poker1 ist eine Methode, um Aufwände relativ zu schätzen. Jedes Teammitgliedbekommt dazu einen Satz Spielkarten, die mit den Zahlen 1, 2, 3, 5, 8, 13 und 21 bedrucktsind (viele Kartensätze enthalten außerdem noch die Werte 0, 40, 100 und ?, wobei das„?“ für „Ich habe eine Frage, die eine Schätzung verhindert“ steht). Die Schätzungen derVergangenheit stellen im weiteren Verlauf die Referenz dar, zu der man relativ schätzt (hatman noch nichts geschätzt, definiert man willkürlich das scheinbar kleinste Element als„3“). Der ProductOwner stellt dann ein Product Backlog Item vor, die Teammitglieder stel-len Fragen. Schließlich wird geschätzt, indem jedes Teammitglied eine Karte verdeckt vorsich hält und alle gleichzeitig umgedreht werden. Die Personen, die den höchsten und denniedrigsten Schätzwert abgegeben haben, begründen, warum sie der jeweiligen Meinungsind. Diskussionen werden vom Scrum Master kurz gehalten. Fachliche Klärungen wer-den vom Product Owner unterstützt. Sind die Meinungen ausgetauscht, bildet sich jederseine Meinung neu und schätzt erneut. Wenn nach drei Durchgängen kein Konsens er-reicht ist, wird im Regelfall der höchsteWert genommen. In Einzelfällen (stark vom Teamabhängig), kann auch die häufigste Nennung gewählt werden. Auf diese Weise erhält mankeine absoluten Schätzungen in Zeit (also zum Beispiel „3 Personentage“), sondern rela-tive Schätzungen. Man weiß also nur, dass eine „13“ fast dreimal soviel Aufwand ist, wieeine „5“. Erst in Verbindung mit der spezifischen Team-Velocity ergibt sich eine Aussa-ge darüber, wie lange eine „5“ wirklich dauert. Der große Vorteil dieser Methode ist, dasssie nicht nur sehr schnell anzuwenden ist, sondern auch bei Veränderungen des Umfelds(Personen wechseln das Team, das Team lernt dazu und wird schneller, vorher unbekann-te Probleme tauchen auf, alte Probleme sind plötzlich gelöst . . . ) nicht jedes Element neugeschätzt werden muss, sondern sich nur die Velocity verändert – die relative Größe der
1 Planning Poker® ist ein registriertes Warenzeichen von Mountain Goat Software, LLC.
185D. Maximini, Scrum - Einführung in der Unternehmenspraxis,DOI 10.1007/978-3-642-34823-5_18,© Springer-Verlag Berlin Heidelberg 2013
186 18 Methoden
Elemente wurde ja nicht beeinträchtigt. Dies spart erheblichen Aufwand und ist daher eine„schlanke“ Schätzmethode.
18.2 Planning Poker für absoluteWerte
DasVerfahren des Planning Pokers kann auch genutztwerden, umabsoluteWerte zu schät-zen. Man versucht also nicht mehr festzustellen, ob ein Element größer oder kleiner ist alsein anderes, sondern man versucht in konkreten Zeiteinheiten zu schätzen. Dies funktio-niert allerdings nur in solchen Fällen gut, in denen die Schätzung lediglich eine kurze Zeitüberdauern muss, also zum Beispiel bei Tasks zu einem Product Backlog Item oder beiImpediments, die bereits aufgetreten sind. Begehen Sie nicht den Fehler, Product BacklogItems absolut abschätzen zu wollen – es wird Ihnen wahrscheinlich nicht gelingen!
Der Grund, weshalb man Planning Poker auch für absolute Schätzungen verwendet,liegt in der Synchronität. Dadurch, dass sich alle Teammitglieder eine Meinung bildenmüssen und diese Meinungen zeitgleich aufgedeckt werden, wird jeder aktiv beteiligt. Sokommen auch ruhigere Personen zum Zug und man bekommt Diskussionen, die sonstverloren gewesen wären.
18.3 Estimation Meeting
Scrum gibt vor, dass ein Product Backlog stets geschätzt sein muss. Scrum sagt aber leidernichts darüber aus, wie diese Schätzung erfolgen soll. Die gängigste Methode dazu ist dasso genannte Estimation Meeting. Der Product Owner lädt idealerweise schonwährend desSprint Plannings dazu ein, damit das Team sich danach richten kann. Anwesend ist das ge-samte Scrum-Team, bei Bedarf auch Spezialisten anderer Teams. Kunden und Stakeholdernehmen nicht teil. Die Timebox sollte zwei Stunden nicht übersteigen, da dann die Kon-zentrationsfähigkeit nachlässt und die Schätzergebnisse schlechter werden. Der ProductOwner bringt sein noch ungeschätztes Backlog mit in den Workshop. Er stellt nacheinan-der seine Anforderungen vor und beantwortet fachliche Fragen des Entwicklungsteams.Technische Fragen werden nicht beantwortet. Sind alle Fragen geklärt, so wird mittels ei-ner Methode wie Planning Poker relativ geschätzt. Natürlich sind auch andere Methodenzulässig. DasHauptziel des EstimationMeetings ist, dass alle Entwickler verstanden haben,worum es bei dem jeweiligen Product Backlog Item geht. Das erleichtert die Kommunika-tion und beugtMissverständnissen vor. Durch diese entstandeneKlarheit ist die Schätzungder Elemente einfach und quasi ein Nebenprodukt. Es gibt keine Beschränkung hinsicht-lich der Häufigkeit der Estimation Meetings. Der Product Owner muss abwägen, ob ersein Team für die Schätzung von der eigentlichen Arbeit abziehen will, oder ob er ein aus-reichend geschätztes Backlog besitzt. Ihm muss dabei klar sein, dass der Scrum Masterdas Sprint Planning abbrechen darf und wird, wenn der Product Owner ohne geschätztes
18.4 Timebox 187
Product Backlog auftaucht. Auch ist eine Vorhersage an die Stakeholder nur mit aussage-kräftigen Schätzungen möglich.
18.4 Timebox
Eine Timebox ist ein festgelegter Zeitraum, der nicht überschritten werden darf. Scrumarbeitet überall mit solchen Timeboxes: Jede Besprechung und jeder Sprint ist zeitlich be-grenzt. Selbst diemeisten Arbeitsschritte während einer Besprechung sind streng eingeteilt(oft gebe ich meinen Workshopteilnehmern eine Timebox von drei oder fünf Minuten).Eine Timebox wird niemals verlängert, da dies die Disziplin gefährden würde. Stattdessenkönnen neue Zeitfenster vereinbart werden.
18.5 Velocity
Die Velocity stellt die Teamgeschwindigkeit dar. Sie ergibt sich aus den Schätzungen derfertigen Features eines Sprints und wird über mehrere Sprints gemittelt. Ein Beispiel: ZuBeginn eines Sprints schätzt ein Team, dass es die drei Features A, B und C schaffen wird.Diese Features hat es zuvor mittels Planning Poker geschätzt. A bekam dabei drei, B achtundCeinundzwanzig Story Points.Nach demersten Sprint hat das Teamdie Product Back-log Items A und B vollständig geliefert, C jedoch nur angefangen. Unfertige Arbeit zähltauch nicht anteilig zur Velocity dazu. Sie beträgt diesen Sprint also elf. Im nächsten Sprintschafft das Team Feature C fertig zu stellen, aber sonst nichts. In diesem Sprint beträgtdie Velocity also einundzwanzig. Die durchschnittliche Velocity des Teams beträgt somitsechzehn ((11 + 21)/2 = 16).
Da jedes Team anders schätzt, lassen sich die Schätzungen verschiedener Teams nichtso einfach vergleichen. In solchen Fällen ist eine Normalisierung notwendig.
Die Velocity wird dazu benutzt, Release- und Sprintplanungen zu erstellen. Wenn allegewünschten Features (bzw. Product Backlog Items) in Story Points geschätzt sind, kanndurch Extrapolation der besten, schlechtesten und durchschnittlichen Velocity ermitteltwerden, welche Features mit welcher Wahrscheinlichkeit zu welchem Zeitpunkt geliefertwerden. Dieses Vorgehen stellt die Grundlage der strategischen Planung dar.
In die Velocity zählen nur solche Product Backlog Items, die sowohl vollständig fertigumgesetzt sind als auch Kundennutzen generieren. Bugs und rein technische Anforderun-gen ohneKundenbezug zählen nicht zur Velocity dazu. Ebenso wenig Besprechungen oderorganisatorische Aufgaben.
