Bye bye, Planning Poker?

Im letzten Jahr habe ich in meinem Artikel Team Estimation Game” ausführlich eine Alternative zum weit verbreiteten Planning Poker vorgestellt. Kürzlich hatte ich endlich die Gelegenheit, diese Schätzmethode in einem Projekt anzuwenden und ich muss sagen: Ich bin beeindruckt. Dies ist mein Erfahrungsbericht.

Die Ausgangssituation:
Ich bin als Agile Coach zu einem Projektteam gestoßen, das seit etwa einem Jahr ein Webportal für einen externen Kunden entwickelte. Der Kunde hatte sehr hohe Ansprüche hinsichtlich Funktionsumfang und kurzfristigem Going Live, so dass das Team unter dem Druck des ersten Releases nach anfänglichen agilen Gehversuchen wieder in einen Command-and-Control-Modus zurückgefallen ist. Da der Kunde nach wie vor einen enormen Releasedruck aufbaute, konnten wir nicht innehalten und das Projekt neu strukturieren, sondern mussten quasi on the fly Änderungen in Richtung einer agilen Arbeitsweise vornehmen. Dies führte dazu, dass wir zunächst einen Sprint mit ungeschätzten Backlog Items durchgeführt haben und uns gerade mitten im zweiten Sprint befanden (ebenfalls mit ungeschätzten Backlog Items), bevor wir das erste Estimation Meeting ansetzen konnten. Auf den ersten Blick klingt dies problematisch, weil wir natürlich keine Velocity berechnen konnten, aber wir haben diesen vermeintlichen Nachteil zu unserem Vorteil nutzen können.

Die Anwendung:
Das Estimation Meeting war für eine Stunde geplant. Es sollten 54 Backlog Items geschätzt werden, davon 9 bereits erledigte aus Sprint 1, 13 aktuell in Arbeit befindliche aus Sprint 2 und 32 noch nicht begonnene Backlog Items. Da es das erste Estimation Meeting für das Team war, haben wir die ersten Minuten genutzt, um den Nutzen des Meetings für alle Beteiligten darzustellen und die Regeln für das anschließende Team Estimation Game zu erläutern.

Die bereits erledigten bzw. im aktuellen Sprint befindlichen Backlog Items musste das Team natürlich nicht mehr “schätzen”, da es sich ja in der Umsetzung bzw. Planung bereits sehr detailliert mit ihnen auseinandergesetzt hatte. Daher habe ich zunächst darum gebeten, diese bereits bekannten Backlog Items nacheinander zueinander in Beziehung zu setzen und an die Wand zu kleben (Sprint 1: grün, Sprint 2: orange). Nachdem dieser Schritt erledigt war, hatten wir bereits ein sieben Zeilen hohes Raster an der Wand. Der nächste Schritt bestand darin, die neuen Backlog Items (blau) sukzessive in Beziehung zu den bereits an der Wand befindlichen zu setzen.

Während des Spiels ergab sich eine Situation, die ich seinerzeit in meinem Artikel nicht berücksichtigt habe: Bezüglich eines Backlog Items gab es dauerhaft auseinanderlaufende Meinungen hinsichtlich dessen Größe; es wurde immer wieder umgehängt, so dass davon auszugehen war, dass hier keine einheitliche Meinung im Team herrschte. Nach dem fünften Umhängen haben wir das Item aus dem Spiel genommen und die umhängenden Kollegen aufgefordert, sich nach dem Meeting auf eine gemeinsame Größe zu einigen. Zwei weitere Items waren selbst dem Product Owner nicht mehr klar, diese haben wir ebenfalls kurzerhand aus dem Spiel genommen.

Am Ende des Spiels hatten wir sieben Zeilen mit jeweils mehreren Karten. Beginnend bei 1 haben wir die Scrum-Fibonacci-Reihe auf das Raster angewandt und so Werte zwischen 1 und 20 für die Backlog Items erhalten (siehe Foto).

Als Reality Check haben wir die Story Points für Sprint 1 und Sprint 2 ausgerechnet: Es waren 107 und 123 Story Points, committed per Bauchgefühl und rückwirkend betrachtet absolut plausibel.

Alles in allem hat das Team die 54 Backlog Items in weniger als einer Stunde geschätzt, d.h. ungefähr eine Minute pro Backlog Item. In Estimation Meetings in früheren Projekten, in denen wir Planning Poker als Schätzmethode eingesetzt haben, habe ich die Schätzung einzelner Items manchmal nach 10 Minuten abbrechen müssen, weil sich das Team in technischen Detaildiskussionen verrannt hatte. Unter diesem Gesichtspunkt ist das Team Estimation Game also ein absoluter Volltreffer: Man bekommt in extrem kurzer Zeit einen guten, groben Überblick über das gesamte Product Backlog.

Aber ist Planning Poker damit endgültig gestorben? Ich denke nicht, denn wir benutzen Planning Poker nach wie vor, um während der Sprints neu hinzugekommene Backlog Items zu schätzen. Meist handelt es sich nur um einige wenige, so dass mit dem Team Estimation Game kaum ein echtes Spiel zustande käme und der Aufwand, die alten Karten wieder an die Wand zu kleben, unverhältnismäßig hoch ist. In diesem Fall greifen wir wieder zu den guten alten Pokerkarten und setzen die neuen Backlog Items mittels Planning Poker in Beziehung zu den bereits erledigten.

Fazit:
Das Team Estmation Game ist für die initiale Product Backlog Schätzung oder eine größere Menge zu schätzender Backlog Items die Methode meiner Wahl, weil man so eine große Menge Items in sehr kurzer Zeit schätzen lassen kann. Wenn bereits ein Grundstock an geschätzen Items besteht und die Anzahl der neu hinzugekommen Items überschaubar ist, greife ich gern wieder auf Planning Poker zurück.

Update 24.03.2010
Mein gelehriger Scrum-Master-Schüler hat mir heute gezeigt, dass es auch anders geht. Er hat einfach die bereits geschätzten Backlog Items auf zwei zusammengeklebten Flipchart-Sheets befestigt, damit der Aufwand für Auf- und Abbau minimiert wird. Nun spielt er auch in den kurzen Estmation Meetings innerhalb eines Sprints das Team Estimation Game mit dem Team. Chapeau!

Autor: Sven Röpstorff

Sven Röpstorff arbeitet freiberuflich als agiler Projektmanager und Coach mit über 16 Jahren Berufserfahrung. Mit seinen Teams probiert er gern neue Wege und Methoden, um sich und sein Umfeld stets weiter zu verbessern. In seinen Vorträgen und Workshops bringt er den Menschen agile Vorgehensweisen auf interessante und spielerische Weise nahe und macht sie somit sichtbar, fühlbar, erlebbar.

11 Kommentare

  1. Methode gefällt mir super!

    Ich kenne leider das Problem, dass man schnell in Estimations und Plannings versinkt, am Schluss doch immer noch ein Risikopuffer hineininterpretiert wird und dann im Sprint natürlich nicht mehr abgearbeitet wird als geplant. (“Arbeit dehnt sich so weit aus, daß die für ihre Fertigstellung zur Verfügung stehende Zeit ausgefüllt wird.” – Parkinson).

    Ich hatte eine Zeit “Quick-Estimations” durchgeführt, in der Stories nur als klein, mittel und groß geschätzt wurden. Wichtig um einen ersten Überblick über das Backlog zu bekommen. Hat auch zu schnellen und hinreichend guten Ergebnissen geführt. Zudem gibt es noch die “Affinity Estimation” (vgl. http://www.armerkater.de/2008/06/affinity-estimating/).

    Die hier vorgestellte Methode gefällt mir aber noch besser!

  2. Moin Felix,

    freut mich, dass Dir die Methode gefällt. Die beiden von Dir erwähnten Methoden kenne ich bisher nur dem Namen nach, werde mich aber mal damit beschäftigen, um mein Estimation-Portfolio abzurunden. Danke auch für den Link.

    Viele Grüße,
    Sven

  3. Hört sich interessant an… werden wir hier auch mal ausprobieren, mal schauen wie viel schneller wir damit werden.

    Frage: Wer hängt denn als erster die Karten an?

    Grüße, Traian

  4. Moin Traian,

    Fall 1: Initiale Schätzung

    Die erste Karte wird hier auch vom Team aufgehängt, nur kann sie natürlich nicht in Relation zu einer bereits hängenden gesetzt werden. Die zweite wird in Relation zu ersten aufgehängt und ab der dritten dürfen Karten auch umgehängt werden. Nachzulesen unter http://www.projekt-log.de/allgemein/team-estimation-game/

    Fall 2: Ergänzende Schätzung während eines Sprints

    Siehe dazu auch mein Update vom 24.03.2010 oben im Artikel. Zu Beginn werden bereits geschätzte Items an die Wand gehängt, so dass gleich das erste neue Item in Relation zu den anderen gesetzt werden kann.

    Melde Dich gern, wenn Du mehr erfahren möchtest.

    Viele Grüße,
    Sven

  5. Hallo Sven,

    danke für deinen interessanten Artikel. Wir haben die Vorgehensweise heute erstmals angewendet, weil ich die technischen Detaildiskussionen abkürzen wollte. Dafür scheint mir dieses Planning Game hervorragend geeignet. Es war auch überhaupt kein Problem, die Stories zueinander ins Verhältnis zu setzen. Wir liefen jedoch in Probleme als wir die Punkte-Skala (Fibonacci mit 0,1,2,3,5,8,13) auf die Cluster anwenden wollten. Wir hatten die unterste (kleinste) Story mit einer 1 bewertet und nach meinem Verständnis hätten die Stories darüber demnach mit einer 2, die wiederum darüber mit 3 usw. bewertet werden müssen, richtig?

    Damit hat man jedoch in jedem Sprint eine neue Referenz-Story und die geschätzten Punkte sind somit nicht mehr von Sprint zu Sprint miteinander vergleichbar. Was hat das für Auswirkungen auf die Velocity? Die ändert sich dann ja auch vor jedem Sprint? Oder verstehe ich da etwas falsch?

    Viele Grüße
    Dirk

  6. Moin Dirk,

    vielen Dank für Deinen Kommentar. Ich bin mir nicht ganz sicher, ob ich die Frage richtig verstehe, ich versuche mich trotzdem mal mit einer Antwort.

    1. Ja, richtig, die Storyzeilen werden von unten nach oben mit den Fibonacci-Werten versehen. Meistens hat man nicht allzu viele Zeilen, falls doch, muss man gemeinsam gruppieren (z.B. die untersten beiden zusammenlegen)
    2. Eine einzelne Referenz-Story wird gar nicht benötigt, da man ja eine neu zu berwertende Story gleich zu allen bereits an der Wand befindlichen Stories in Beziehung setzt.
    3. Idealerweise schätzt man zu Beginn das komplette (zu dem Zeitpunkt vorliegende) Backlog und später nur die neu hinzugekommenen Stories. Damit man für die neuen Stories weiterhin Referenzen hat, empfehle ich, die bereits geschätzten Stories wieder an die Wand zu pappen. Sollten es zu viele sein, würde ich ein paar (vielleicht 20) relativ aktuelle Stories aus der vollen Fibonacci-Range auswählen. Damit ist auch die Velocity vergleichbar.

    Ich hoffe, die Antwort hilft Dir weiter, sonst melde Dich einfach nochmal, gern auch per Mail: sven@agiletransparency.com

    Viele Grüße,
    Sven

  7. Pingback: Estimation – Bewahre die Magie | PROJEKT-LOG

  8. Hallo,

    gibt es denn Erfahrungen damit, ob beim Team Estimation Game das Anhängen der Story Cards an einer Wand oder das Auslegen der Story Cards auf einem Tisch (vgl. Artikel von Joachim Seibet “Agiles Schätzen im Team: Verfahren in der agilen softwareentwicklung” im OBJEKTspektrum 5/2012 sowie http://infos.seibert-media.net/display/Websoftware/Agile+Vorhersagen) oder das Auslegen auf dem Boden (mein Vorschlag / “Die Schätzung liegt dem Team zu Füßen.”) zielführender ist.

    Ulrich

  9. Moin Ulrich,

    ich mache den Ort für das Anhängen der Story Cards von den örtlichen Gegebenheiten abhängig. Bis auf eine Ausnahme hatte ich immer eine senkrechte Fläche (Wand, Metaplanwand, Fenster, …) zur Verfügung, einmal bin ich auf einen Tisch ausgewichen. Die Wand hat den Vorteil, dass die Teilnehmer die Story Cards recht gut sehen können, bei einem Tisch oder dem Fußboden würde man sich eher “ballen”, um nicht über Kopf lesen zu müssen. Echte Erfahrungswerte habe ich nicht, würde aber aus den o.a. Gründen und aus dem Bauch heraus die senkrechte Fläche für das Team Estimation Game vorziehen.

    Magic Estimation hingegen (siehe auch http://www.projekt-log.de/scrum/magic-estimation/) lasse ich an einem Tisch spielen, da es hier nicht auf den direkten Vergleich mit den bereits liegenden Karten ankommt, sondern auf die indviduelle Zuordnung. Müsste man die Karten an die Wand pinnen oder kleben, käme man sich dauernd in die Quere.

    Den Vergleich “Die Schätzung liegt dem Team zu Füßen” finde ich allerdings klasse :)

    Danke für den Kommentar und viele Grüße,
    Sven

  10. Hallo Sven,

    ein sehr interessantes und effizientes Verfahren.
    Ein wesentlicher Punkt beim Planning Poker ist, dass die Spieler sich beim Schätzen nicht beeinflussen. Beim Team Estimation Game besteht zwar die Möglichkeit des Umhängens, ein erster Anker ist aber durch den ersten Schätzer gesetzt und dürfte die Umhängenden beeinflussen (falls sie überhaupt umhängen).
    Wie denkst Du darüber?

    Grüße
    Gerhard

    • Moin Gerhard,

      vielen Dank für deinen Kommentar. Du hast recht, durch den ersten Schätzer wird ein Anker gesetzt. Der Anker steht aber frei im Raum, d.h. die Story ist noch nicht mit Story Points versehen. Alle folgenden Stories werden nun relativ zu der ersten bzw. allen an der Wand hängenden Stories eingeordnet. Am Ende kann die erste Story auch die größte sein, wenn alle anderen kleiner eingestuft werden. Erst ganz am Schluss werden die Story Points zugeordnet.

      Weiter erklärt jeder Teilnehmer kurz, warum er seine Story an genau die Stelle hängt, die er ausgewählt hat. Und es wird tatsächlich intensiv umgehängt, ich musste sogar schon Stories aus der Schätzung nehmen, weil sie pingpong-artig umgehängt wurden.

      Ich hoffe, das beantwortet deine Frage?

      Viele Grüße,
      Sven