Scrum-Leitfaden | 25. Teamschätzungsspiel

Veröffentlicht: 2022-05-28

Team Estimation Game ist eine Technik, die die Sprintplanung in Scrum erleichtert. Wie unterscheidet es sich von Planning Poker? Warum halten einige Entwicklungsteams es für ein effektiveres Tool und andere nicht? Alles, was Sie dazu wissen müssen, finden Sie im folgenden Artikel.

Mannschaftsschätzungsspiel – Inhaltsverzeichnis:

  1. Einführung
  2. Regeln des Teamschätzungsspiels
  3. Teamschätzungsspiel versus Planungspoker
  4. Zusammenfassung

Einführung

Das Team Estimation Game wird auch Swimlanes Estimation genannt. Der letztgenannte Begriff entstand als spontane Beobachtung eines Kartenspiels, da die Anzeige der Karten den Schwimmbahnen eines Wasserbeckens ähnelte.

Team Estimation Game gewinnt ständig an Popularität, da es Entwicklungsteams ermöglicht, Schätzungen etwa dreimal schneller zu erstellen als mit Planning Poker.

Wir haben über diese Technik im vorherigen Artikel geschrieben. Konzentrieren wir uns heute auf das Teamschätzungsspiel.

Regeln des Teamschätzungsspiels

Eingabeaufforderungen für das Teamschätzungsspiel:

  • ein Kartenspiel mit User Storys – separat für jedes Spiel vorbereitet
  • ein Stapel Story Point-Karten – zur wiederholten Verwendung

Stapeln Sie zuerst die User Stories-Karten in der Reihenfolge, die den Einträgen im Product Backlog entspricht. Um sicherzustellen, dass die dringendsten zuerst geschätzt werden.

Die Wertungskarten enthalten normalerweise Werte, die der Fibonacci-Folge entsprechen. Dies ist eine Folge der folgenden Zahlen: 0, 1, 3, 5, 8, 13, 20, 40 und 100. Sie können sie auch mit aufeinanderfolgenden Potenzen der Zahl 2 kennzeichnen, also 2, 4, 8, 16, 32 usw.

Team Estimation Game

Die Phasen des Teamschätzungsspiels:

  1. Einführung. Um das Team Estimation Game zu spielen, sitzen die Mitglieder des Scrum Teams um einen Tisch. Der Product Owner beginnt damit, die erste Karte aus dem User Story-Deck zu ziehen und ihren Inhalt mit allen zu teilen. Dann bleiben die Karten auf dem Tisch. Dann erklärt der Product Owner dem Rest des Scrum-Teams, dass die Spieler User Storys von nun an als leicht oder schwer umsetzbar bewerten werden, indem sie sie entsprechend links und rechts platzieren. Wenn einer einen gewissen Schwierigkeitsgrad hat, stapelt der Spieler zusammen, eines über dem anderen auf dem Tisch. Jetzt macht die Person, die im Uhrzeigersinn neben ihnen sitzt, den nächsten Zug.
  2. Ein Spieler zieht eine Karte vom User-Story-Stapel. Nachdem der Inhalt mit allen geteilt wurde, erklärt er dem Product Owner seine Essenz. Die Person, die die Karte hält, legt sie dann auf den Tisch und wählt einen Platz basierend auf ihrer Meinung über die Schwierigkeit dieser User's Story aus. Dann erklärt der Spieler allen die Gründe für die Wahl und der andere Spieler kann Fragen zur Begründung stellen. Sie können nicht die Entscheidung selbst in Frage stellen, sondern die Argumente, die die Entscheidung rechtfertigen.
  3. Nun sind die Spieler an der Reihe und haben zwei Optionen zur Auswahl:
    • Wiederholen Sie Schritt 2, oder
    • Bewegen Sie eine der Karten auf dem Tisch an die am besten geeignete Position

    Wenn sie sich für die zweite Option entscheiden, sollten sie auch begründen, warum sie ihre Meinung geändert haben. Die Spieler wiederholen abwechselnd Schritt 3, bis alle Karten aus dem User-Story-Stapel verteilt und geschätzt wurden.

  4. Die letzte Phase des Platzierens der User Story-Karten erfolgt einmal oder mehrmals, je nach Vorgehensweise des Scrum-Teams. Während dieser Runde hat jeder Spieler noch eine weitere Gelegenheit, eine der Karten auf dem Tisch an einen geeigneteren Platz zu verschieben.
  5. Sobald die Spieler alle User Story-Karten ihren Orten zugewiesen haben, die die Schwierigkeitsgrade darstellen, geht das Entwicklungsteam weiter, um den Wert abzugleichen, indem es die Karten aus dem Story Point-Stapel zuweist. Die erste User-Story-Karte links erhält die Story-Point-Karte mit der niedrigsten Punktzahl vom Product Owner. Die Regel für das Ablegen weiterer Karten ist die gleiche wie bei den Punkten 3 und 4. Damit ist die Schätzung abgeschlossen.
Team Estimation Game

Teamschätzungsspiel versus Planungspoker

Das Teamschätzungsspiel gilt als effektiveres Schätzungstool als Planning Poker. Aufgrund der folgenden Unterschiede zwischen diesen beiden Techniken:

  • Kartentisch. Das Teamschätzungsspiel verwendet die bekannte „Kartentischregel“ aus beliebten Kartenspielen. Das bedeutet, dass Sie eine einmal platzierte Karte nicht mehr zurücknehmen können. Da User Story jeweils von einer Person geschätzt wird, ist die Schwankung zwischen den Schätzungen und der Anzahl der Positionswechsel im Vergleich zu Planning Poker deutlich geringer.
  • Eine ausreichend genaue Berechnung. Beim Planning Poker sollte für jede User Story ein vollständiger Konsens erreicht werden. Beim Team Estimation Game hingegen entscheidet nur eine Person. Selbst wenn seine/ihre Schätzung falsch ist, wird ein anderer Entwickler wahrscheinlich darauf abzielen, seinen Wert genauer zu treffen. Auf diese Weise wird garantiert, dass eine ausreichend genaue und schnelle Schätzung erreicht wird
  • Erschöpfung des Diskussionsthemas. Argumentierende Entscheidungen werden beim Spielen von Planning Poker oft übermäßig lang. Ihre Zeit wird während eines Teamschätzungsspiels stark reduziert, da sie sich auf eine einzelne Entscheidung eines der Entwickler konzentrieren und nicht auf die Art jeder User Story.

Ein möglicher Nachteil des Team Estimation Game ist ein Gefühl der Unfairness. Wenn das Entwicklungsteam größer ist als die Anzahl der in einem bestimmten Sprint geplanten User Storys, fühlen sich einige Entwickler möglicherweise ausgeschlossen.

Teamschätzungsspiel – Zusammenfassung

Team Estimation Game hat eine Meinung über die effektivste Schätztechnik für die meisten Scrum-Teams. Es ist jedoch wichtig zu bedenken, dass es sich nur um ein Werkzeug handelt, um die Schwierigkeit und den Aufwand von User Stories abzuschätzen. Und wie jedes Tool sollten wir es an die Bedürfnisse und Fähigkeiten der Teammitglieder anpassen.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 25. Team Estimation Game caroline becker avatar 1background

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

  1. Glossar der Grundbegriffe, Rollen und Begriffe
  2. Was ist Scrum?
  3. Scrum-Werte
  4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
  5. Scrum Team – was ist das und wie funktioniert es?
  6. Wer ist ein Product Owner?
  7. Die häufigsten Fehler des Product Owners
  8. Wer ist der Scrum-Master?
  9. Eigenschaften eines guten Scrum Masters
  10. Die häufigsten Fehler des Scrum Masters
  11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
  12. Zusammenarbeit zwischen Product Owner und Scrum Master
  13. Entwicklungsteam in Scrum
  14. Die häufigsten Fehler von Entwicklern
  15. Scrum-Artefakte
  16. Scrum skalieren
  17. Sprint-Rückstand
  18. Was ist das Product Backlog?
  19. Was sind User Stories?
  20. Erstellen Sie die beste User Story mit INVEST
  21. Die häufigsten Fehler in User Storys
  22. Akzeptanzkriterien für User Storys
  23. Schätzung und Story Points in Scrum
  24. Planungspoker
  25. Team-Schätzspiel
  26. Inkrement definieren
  27. Scrum-Ereignisse
  28. Was ist Sprint in Scrum?
  29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
  30. Was ist ein Burndown-Diagramm?
  31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
  32. Vor- und Nachteile des Burndown-Charts
  33. Kanban-Boards in Scrum und Scrumban
  34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
  35. Tägliches Scrum
  36. Sprint-Planung
  37. Sprint-Review
  38. Was ist eine Sprint-Retrospektive?
  39. Häufige Fehler während einer Sprint-Retrospektive
  40. Pflege des Produkt-Backlogs