Team Estimation Game

English
Team Estimation Game

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.

Team Estimation Game
Herunterladen Download PDF
Herunterladen Download PDF (English)

Team Estimation Game

English
Team Estimation Game

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.

Team Estimation Game
Wir empfehlen zum Thema Agile Methoden
3 x 4 Stunden
07.11.2024
1.295,00,-
User Story Mapping - Die Nutzer im Blick mit der Produkt-Landkarte

Stellen Sie Kundenanforderungen – ohne endlose Dokumentationen – strukturiert dar und behalten Sie mit diesem Seminar die Kontrolle über den gesamten Entwicklungsprozess. Mit vielen Praxisübungen und direkt anwendbar. Mehr Infos

Einsatzmöglichkeiten

Das Team Estimation Game wird für die Aufwandsschätzung aus zwei Perspektiven eingesetzt:

  • Bestimmung der in einem Sprint durchführbaren Arbeitspakete (nach dem Minimalprinzip: "Wie viele User Storys können wir im kommenden Sprint fertig stellen?")
  • Bestimmung des Aufwands zur Abarbeitung eines vollständigen Product Backlogs (folgend dem Maximalprinzip: "Wie viel Aufwand bedeutet die Abarbeitung aller Product Backlog Items?")

 

Ergebnisse
  • Nach Aufwand geordnete User Storys. Die User Storys werden anhand des geschätzten Aufwandes (niedrig – hoch) an einer Tafel oder auf einer anderen Fläche angeordnet.
  • Story-Points für jede geschätzte User Story. Die einzelnen User Storys des Product Backlogs aus dem Eingangskanal wurden bezüglich ihres Aufwands geschätzt.
  • Hinweise auf Unsicherheiten und mangelnde Klarheit bei den Anforderungen. Während des ersten Durchgangs aufkommende Unklarheiten werden geklärt oder zur Klärung zurückgestellt.
Vorteile
hohe Genauigkeit der Schätzung durch die kollektive Betrachtung gegenüber individuellen Schätzungen
Einschätzung aus unterschiedlichen Perspektiven, je nach Zusammenstellung des Teams
geringerer Aufwand als die Schätzung durch Zerteilung der User Storys, bzw. der Arbeitspakete in Teilaufgaben
einfaches Setup
kurzes, intuitiv verständliches Regelwerk
Neue Teammitglieder mit Kenntnis der Methode können direkt in Schätzrunden eingebunden werden.
Durch die Gestaltung als Spiel wird die aktive Mitarbeit in der Gruppe gefördert (aktives Feedback statt einseitiger Vortrag).
Grenzen, Risiken, Nachteile
Einmal eingeführt kann die Methode schwer ersetzt werden. Andere Schätzmethoden verwenden andere Bezugsgrößen und Bewertungsmetriken.
Ab einer Gruppengröße von mehr als neun Personen dauert eine Runde mehrere Minuten. Der Vorteil der schnellen Abarbeitung einzelner User Stories bzw. Arbeitspakete entfällt.
Ohne ausreichenden fachlichen Hintergrund der Teilnehmer wird die Schätzung spekulativ
Voraussetzungen
  • ein Scrum Team, bzw. eine Gruppe von Personen, die für die Abarbeitung der User Storys in Frage kommt
  • Besprechungsraum, in dem die Schätzungen ungestört durchgeführt werden können; ausreichend Fläche zur Ablage und Sortierung der einzelnen User Storys.
Qualifizierung
  • Der Leiter des Workshops sollte einschlägige Moderationserfahrung haben.
  • Alle Teilnehmer müssen die Regeln des Team Estimation Games kennen.
  • Sind die Spielregeln des Team Estimation Games einigen Teilnehmern nicht bekannt, ist eine kurze Erklärung der Regeln notwendig.
Benötigte Informationen
  • vom Product Owner priorisiertes Product Backlog für die Schätzung eines Projekts
  • Sprint Backlog für die Überprüfung eines Sprints
  • Expertise der Teilnehmer für die zu schätzende Aufgabenstellung.
Benötigte Hilfsmittel
  • Moderationskarten mit den User Storys des Product bzw. Sprint Backlogs
  • Pinnwand zur Sammlung und Sortierung der geschätzten User Storys. Alternativ können die Karten auch an der Wand angebracht oder auf einem großen Tisch bzw. dem Boden ausgelegt werden.
  • Moderationsmaterialien (Karten, Stifte, Pin-Nadeln, Klebestreifen, Flip-Chart) zur Bearbeitung und Darstellung der Ergebnisse
  • Karten mit Zahlenwerten (z.B. Fibonacci-Zahlen) zur Bewertung der User Storys im späteren Verlauf. Die Zahlenwerte entsprechen der Messgröße Story Point und werden mit den User Storys als Ausgangsgröße übergeben
Herkunft

Die Methode geht auf Steve Bockman zurück, der sie erstmals 2008 anwendete (Agile Unlimited, http://agileunlimited.com/whoweare.php, zuletzt besucht am 19.8.2015).

Durchführung: Schritt für Schritt

Schritt 1: Bereiten Sie das Team Estimation Game vor!

Ü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:

  • Product Owner: Er vertritt die Seite des Auftraggebers, priorisiert das Product Backlog und steht den Schätzern zur Klärung von Fragen bzgl. der User Stories zur Verfügung. Der Product Owner nimmt keinerlei Einfluss auf die Schätzung: er gibt weder Schätzungen ab noch beeinflusst er die Teilnehmer.
  • Scrum Master: Er organisiert den Termin, achtet auf die Einhaltung der Spielregeln und moderiert den Ablauf des Team Estimation Games. Der Scrum Master nimmt ebenfalls keinen Einfluss auf die Schätzung.
  • Entwickler: Sie realisieren später die User Storys. Durch ihre Expertise aus anderen Projekten liefern sie den essentiellen Beitrag zum Team Estimation Game. Die Entwickler liefern die Schätzungen, ggf. geben auch Spezialisten Schätzungen ab (s.u.).
  • Spezialisten: Ist Ihnen vorab bekannt, dass bei den Entwicklern fachliche Wissenslücken vorhanden sind, können Sie die Runde durch Experten für diese Themen ergänzen. Diese unterstützen das Team, indem sie fachliche Rückfragen beantworten und beteiligten sich bei denjenigen User Stories an der Schätzung, für die sie Experten sind.

Der Scrum-Master schlägt die Reihenfolge der Teilnehmer vor (z.B.: reihum oder freiwillige Meldung) und initiiert die erste Schätzrunde.

Schritt 2: Die erste User Story wird platziert

Die erste Person aus dem Team liest diese laut vor und positioniert sie danach mittig auf der vorgesehenen Fläche (Boden, Wand, Whiteboard, Flipchart...).

Schritt 3: Zwei weitere User Storys werden platziert

Die zweite Person aus dem Team liest die nächste Story laut vor und positioniert sie links oder rechts neben der ersten Story:

  • LINKS neben einer Story bedeutet, dass der Spieler den Aufwand seiner Story geringer schätzt als den Aufwand der bereits positionierten Story.
  • RECHTS neben einer Story bedeutet, dass der Spieler den Aufwand seiner Story höher einschätzt.

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.

Schritt 4: Erweitern Sie das Regelwerk!

Erweitern Sie jetzt die Spielregeln, ab der vierten User Story ist zusätzlich möglich:

  • Der am Zug befindliche Spieler kann darauf verzichten, eine neue Story zu platzieren und stattdessen eine bereits abgelegte Story verschieben. Er kann z.B. die Story A, die zunächst links von Story B war, nach rechts verschieben, so dass sie sich jetzt rechts von Story B befindet. Der Spieler kann diese Aktion ggf. kurz erklären, aber es gibt hierzu keine Diskussion.
  • Die Person am Zug kann aussetzen, wenn sie keine Änderung durchführen möchte und alle User Storys platziert sind.

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.

Schritt 5: Die Spieler platzieren die verbleibenden User Storys

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:

  • alle User Storys auf der vorgesehen Fläche angebracht wurden.
  • alle beteiligten Personen aussetzen, also alle Teilnehmer mit den Schätzungen zufrieden sind.

Schritt 6: Bewerten Sie die User Storys mit Zahlenwerten!

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

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:

  • jeder User Story ein Wert zugeordnet ist,
  • alle Teilnehmer passen, d.h. mit der Bewertung einverstanden sind.

Schritt 7: Übergeben Sie die Ergebnisse an die Schnittstellen!

  • Überführen Sie die Ergebnisse (User Storys inklusive Konsens-Schätzungen) in das Product Backlog.
  • Übersetzen Sie die Bewertungsergebnisse in die Ressourcen- und Einsatzplanung und / oder Ihr Risikomanagement.
  • Geben Sie Ihre Dokumentation der Unklarheiten an den Product Owner weiter (fachlich zu den einzelnen User Storys und / oder die Anforderung eines entsprechenden Spezialisten), sofern dies nicht während der Durchführung geschehen ist.

Praxistipps

Gehen Sie pragmatisch vor

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.

Achten Sie auf Ihre Skala

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:

  • Es liegt bereits die Schätzung eines Product Backlogs vor. Während einer späteren Schätzung eines Sprint Backlogs wird erkannt, dass die bestehende Zahlenskala nicht ausreicht.
  • Wenn mehrere Sprints nacheinander geschätzt werden, ergibt sich durch bewusste oder unbewusste Vergleiche mit den vergangenen Sprints die Notwendigkeit, die Skala zu erweitern.
  • Ein Sprint wird abgebrochen und nach einem Review eine neue Schätzung durchgeführt. Eine oder mehrere User Storys werden aufgrund der neuen Erkenntnisse außerhalb der bisherigen Skala einsortiert.

 

Varianten

Dynamic Team Estimation

Dynamic Team Estimation ist für größere Teams geeignet, die bereits das Team Estimation Game beherrschen (bis drei mal neun Personen, neun entspricht der maximalen Größe einer Team Estimation Game-Gruppe). Im Gegensatz zur klassischen Variante werden beim Dynamic Team Estimation die User Storys des Product Backlogs nicht sequentiell, sondern parallel bearbeitet. Dies bedeutet, dass mehrere User Storys in kleinen Arbeitsgruppen geprüft und Argumente ausgetauscht werden.

Teilen Sie vor Beginn die zu behandelnden User Storys unter den Teams gleichmäßig auf. Die Abgabe der Schätzungen erfolgt an einer gemeinsamen Fläche. Dazu werden zu Beginn des Dynamic Team Estimation Games aus jeder Gruppe drei Repräsentanten ausgewählt (entsprechend der maximalen Größe drei mal drei Personen). Diese sind für die Abgabe der Schätzungen verantwortlich.

Wichtig: Wenn ein Teilnehmer eine User Story auf der Arbeitsfläche platziert und die Gründe hierfür vorträgt, unterbrechen alle Arbeitsgruppen ihre Tätigkeit, um die Platzierung und die zugehörigen Argumente wahrzunehmen.

Die Abweichung vom stark sequentiellen Ansatz des Team Estimation Game ermöglicht einen höheren Durchsatz an User Storys. Der Nachteil am Dynamic Team Estimation ist der hohe Anspruch an die Disziplin der Teilnehmer. Die Unterbrechung der Tätigkeiten und Konzentration auf die Argumente und Einordnung einer einzelnen User Story muss schnell von statten gehen, um den Vorteil dieser Methode auszuspielen. Dies erfordert eine gezielte Moderation und notfalls einen Eingriff in das Geschehen bei Missachtung dieser zusätzlichen Spielregel.

Ergänzende Methoden

Planning Poker

Schätzen Sie spielend einfach die relativen Aufwände für die User Storys oder anderen Aufgaben zusammen mit dem Umsetzungsteam!

Fachartikel zur Methode

In der agilen Software-Entwicklung wird der Leistungsumfang üblicherweise mit User Stories beschrieben und der jeweilige Entwicklungsaufwand in der relativen Einheit "Story Point" geschätzt.

Herunterladen Download PDF
Herunterladen Download PDF (English)

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
4 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 7
Kommentare 4

Alle Kommentare (4)

Guest

Mir ist die beschriebene Technik als "Affinity Estimating" bekannt, die 2008 von Lowell Lindstrom auf dem Scrum Trainers Gathering vorgestellt wurde. Link: http://kanemar.com/2008/04/21/scrum-trainers-gathering-44-affinity-estimating/

 

Guest

Mir war die Methode bisher unbekannt, ich finde sie hier aber toll erklärt! Die Darstellung ist sehr übersichtlich, man findet auf einen Blick alles, was man braucht. Damit lässt sich gut arbeiten.

 

Profile picture for user frank-dieter.berg@lb-solutions.de
Frank-Dieter
Berg

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.

Profile picture for user frank-dieter.berg@lb-solutions.de
Frank-Dieter
Berg

Hie noch die Bewertung