
Svenja Reimann
19.10.2015
- Anmelden oder Registieren, um Kommentare verfassen zu können
Das Team Estimation Game dient der relativen Aufwandsschätzung von Product Backlog Items bzw. von Arbeitspaketen eines Projekts in kleinen Gruppen. Die Methode wird hauptsächlich in agilen Vorgehensmodellen angewendet (z.B. SCRUM) und ermöglicht eine direkte Schätzung durch die Mitglieder des Umsetzungsteams. Die Methode basiert auf der Annahme, dass detaillierte Aufwandsschätzungen für die einzelnen Aufgaben eines Product Backlog Items, bzw. eines Arbeitspakets, nicht praktikabel sind. Grund dafür ist, dass die Tätigkeit der Schätzung selbst sehr aufwendig ist, da die Aufgaben bzw. Backlog Items hierzu in schätzbare Einzeltätigkeiten zerlegt werden müssen. Die relative Schätzung der User Storys durch ein Team verspricht demgegenüber eine hohe Zeitersparnis bei vergleichbar genauem Ergebnis.
Das Team Estimation Game dient der relativen Aufwandsschätzung von Product Backlog Items bzw. von Arbeitspaketen eines Projekts in kleinen Gruppen. Die Methode wird hauptsächlich in agilen Vorgehensmodellen angewendet (z.B. SCRUM) und ermöglicht eine direkte Schätzung durch die Mitglieder des Umsetzungsteams. Die Methode basiert auf der Annahme, dass detaillierte Aufwandsschätzungen für die einzelnen Aufgaben eines Product Backlog Items, bzw. eines Arbeitspakets, nicht praktikabel sind. Grund dafür ist, dass die Tätigkeit der Schätzung selbst sehr aufwendig ist, da die Aufgaben bzw. Backlog Items hierzu in schätzbare Einzeltätigkeiten zerlegt werden müssen. Die relative Schätzung der User Storys durch ein Team verspricht demgegenüber eine hohe Zeitersparnis bei vergleichbar genauem Ergebnis.
Das Team Estimation Game wird für die Aufwandsschätzung aus zwei Perspektiven eingesetzt:
Überprüfen Sie als Moderator / Scrum Master mit dem Product Owner, ob alle User Storys in der aktuellen Fassung vollständig vorliegen. Die Methode umfasst mindestens die Schätzung eines Sprint Backlogs bis hin zur Schätzung eines Product Backlogs.
Stellen Sie sicher, dass alle zu behandelnden User Storys auf Moderationskarten gedruckt / geschrieben werden. Gesammelt in einem Kartenstapel bilden sie die Grundlage der nun folgenden Schätzung. Eine spezielle Sortierung der User Stories ist nicht erforderlich.
Benennen Sie bei der Einladung zum Team Estimation Game das zu schätzende Vorhaben (Ihr Projekt, optional auch die einzelnen User Storys). Ergänzen Sie bei der erstmaligen Anwendung Hinweise zur Methode Team Estimation Game. Planen Sie, sofern die Methode bei den Teilnehmern unbekannt ist oder erstmalig angewendet wird, Zeit für eine kurze Erklärung ein. Eine ausführliche Trainingsrunde ist aufgrund des einfachen Regelwerks nicht erforderlich.
Achten Sie darauf, dass das Projektteam vollständig vertreten ist. Die Teamrollen im Detail:
Der Scrum-Master schlägt die Reihenfolge der Teilnehmer vor (z.B.: reihum oder freiwillige Meldung) und initiiert die erste Schätzrunde.
Die erste Person aus dem Team liest diese laut vor und positioniert sie danach mittig auf der vorgesehenen Fläche (Boden, Wand, Whiteboard, Flipchart...).
Die zweite Person aus dem Team liest die nächste Story laut vor und positioniert sie links oder rechts neben der ersten Story:
Hinweis: Üblich ist die Platzierung von links nach rechts für steigenden Aufwand. Sie können alternativ die Karten auch von unten (niedriger Aufwand) nach oben (hoher Aufwand) positionieren. Welche Anordnung Sie wählen, ist für die Methode irrelevant, Sie sollten aber die Richtung während des Spiels unbedingt beibehalten, um Verwirrungen zu vermeiden.
Der am Zug befindliche Spieler erklärt den Grund für seine Einordnung in wenigen Sätzen. Alternativ kann auf eine Erklärung verzichtet werden. Die Entscheidung wird bei diesem Schritt nicht diskutiert. Klärende Verständnisfragen zwischen Entwicklern und Spezialisten sind erlaubt.
Der dritte Spieler platziert die dritte User Story in gleicher Weise.
Erweitern Sie jetzt die Spielregeln, ab der vierten User Story ist zusätzlich möglich:
In diesem Schritt werden auch User Storys mit ähnlichem Aufwand ausschließlich in die Reihe einsortiert, es gibt nicht die Möglichkeit, die Aufwände für zwei User Storys als gleich oder ähnlich zu kennzeichnen. Dies erfolgt erst in Schritt 6.
Führen Sie nun die Aufwandsschätzung nach diesem Regelwerk mit allen verbliebenen User Storys durch. Kann eine User Story aufgrund fehlender Informationen nicht geschätzt werden, wird dies vom Scrum Master / Moderator dokumentiert und die User Story zurück an den Product Owner gegeben. Dies gilt auch für die Zuordnung der User Stories zu Zahlenwerten im folgenden Schritt.
Das Anordnen der User Storys und die damit verbundene Aufwandsschätzung sind abgeschlossen, wenn:
Nun tragen Sie entlang Ihrer sortierten User Storys die vorbereiteten Zahlenkarten auf, so dass eine Skala entsteht. Positionieren Sie die Karte mit dem kleinsten Zahlenwert bei der User Story, deren Aufwand am geringsten geschätzt wurde. Dementsprechend sollte der größte Zahlenwert bei der User Story mit der höchsten Aufwandsschätzung zu finden sein.
Zwischen diesen beiden Extremwerten gilt es nun, die einzelnen User Storys zu gruppieren und diese Gruppen jeweils einer Zahl zuzuordnen. Es ist hierbei Ihre Entscheidung, ob Sie die User Storys in der Anordnung aus Schritt 5 belassen, oder ob sie identische Aufwände neu sortieren (z.B. untereinander bei der üblichen Links-Rechts-Sortierung). Folgendes Beispiel zeigt die Zuordnung bei unveränderter Sortierung:
Bild 1: Ergebnis des Team Estimation Games
Hinweis: Als Zahlenskala bietet sich die Fibonacci-Folge (1, 1, 2, 3, 5, 8, 13 usw.) an, da diese nach oben starke Unterscheidungen zwischen den Zahlenwerten aufweist. Dies ermöglicht eine klare Unterscheidung zwischen subjektiv als aufwendig oder weniger aufwendig eingeschätzten User Storys.
Die Teammitglieder führen die Zuordnungen ebenfalls reihum durch. Pro Person und Schätzung (= eine Runde) ist jeweils entweder eine Zuordnung oder eine Umsortierung möglich (analog zu Schritt 5). Die Runden zur Schätzung enden, wenn:
Bei der Einordnung der User Storys auf der Spielfläche ist es nicht wichtig, ob eine User Story A "nur etwas" mehr bzw. weniger aufwendiger ist als eine User Story B. Machen Sie das den Teilnehmern klar und beenden Sie jede Diskussion darum. Wichtig ist die pure Einordnung in: größer, kleiner oder (in Schritt 6) gleich aufwendig.
Idealerweise können Sie die Einordnungen der User Storys in Schritt 6 der Methode in sieben bis neun Bereiche vornehmen. Dies hat sich in vielen Berichten als praktikabel erwiesen.
Auf jeden Fall müssen Sie damit rechnen, dass die Skala bei späteren Schätz-Workshops verbreitert wird, da neue Aufgaben über die Enden der bisherigen Skala hinaus eingeordnet werden. Gründe hierfür können z.B. sein:
Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.
19.10.2015
16.05.2019
Wir haben die Methodik bisher in Projekten 2 mal durchgeführt und waren ziemlichzufrieden. Sie ermöglicht es auch mit einem nicht sehr erfahrenen Team strukturiert und in recht kurzer Zeit zu einer Einschätzung des Aufwands zu gelangen. Ich kann es nur empfehlen.
16.05.2019
Hie noch die Bewertung
Dieter Bertsch
24.09.2015