Statt Planning Poker: Flag Estimation

Grafik: Wikimedia Commons/Acme Squares - CC BY-SA 3.0

Zu den immer wiederkehrenden Herausforderungen eines Scrum Masters gehört sicherlich die Neigung von Product Ownern, Projektleitern aber auch einfachen Teammitgliedern, Stories nicht in Komplexität, bzw. Story Points sondern in Arbeitsstunden oder Personentagen messen zu wollen. Der Ursache dafür ist im Normalfall nicht, dass die Gründe für die Nutzung von Story Points unklar wären. Die sind bekannt und schnell erklärt:

• Menschen können sehr schlecht Zeitaufwände schätzen (brauche ich dafür 5 oder 8 Stunden?) aber sehr gut Aufgaben in Relation setzen (A ist größer als B).
• Zeitaufwände müssen ständig neu geschätzt werden weil eingespielte Teams schneller werden und Teams deren Mitglieder ausgetauscht werden langsamer. Komplexitäts-Schätzungen bleiben gleich.
• Schätzungen von Zeitaufwänden führen oft (und z.T. unbewusst) zu unrealistischem Planungsoptimismus, wenn einfach die verbleibende Zeit auf die geplanten Features aufgeteilt wird. Bei Komplexitäts-Schätzungen besteht dieses Risiko nicht.

Dass es trotzdem regelmässig zu Rückfällen in Zeitschätzungen kommt liegt an verschiedenen Gründen: Alte Gewohnheiten oder im Hintergrund wühlende Abteilungsleiter sind Klassiker, erstaunlich oft liegt die Ursache aber auch da wo man sie am wenigsten vermuten würde, nämlich in einem klassischen agilen Werkzeug - den Planning Poker-Karten. Auf diesen befinden sich nämlich Zahlen, und selbst wenn diese explizit nicht dafür gedacht sind Tage oder Stunden darzustellen, so ist es für viele Menschen einfach zu naheliegend oder zu verlockend genau das zu machen. Was soll man aber mit einem Team anstellen, das sich beim besten Willen nicht davon abbringen lässt die Karten in dieser Weise zu missbrauchen?

Ein interessanter Lösungsansatz den ich einmal im Bordbistro eines Zuges mitbekommen habe (man lernt dort mitunter bemerkenswerte Leute kennen) ist der, statt klassischen Planning Poker-Karten ausgedruckte Fahnen verschieden großer Länder zu benutzen. Eine sehr kleine Story wäre z.B. Luxemburg, eine etwas größere Estland, dann die Niederlande, dann Spanien, dann Deutschland, bis hin zu den ganz großen: Brasilien, Russland, USA und schließlich als größte Karte China. Die so dargestellten Größeneinheiten sind noch immer eingängig, die Umrechnung in Tage und Stunden wird dagegen deutlich erschwert. Die dabei entstehende Herausforderung ist allerdings die, dass aus den Stories eines Sprints eigentlich eine Durchschnittsleistung/Velocity abgeleitet werden muss, was bei Karten mit Nummern darauf deutlich einfacher ist. In diesem konkreten Fall löste das Team diese Schwierigkeit dadurch, dass die Karten auch unterschiedlich groß waren. Nebeneinandergelegt entsprachen sie bestimmten Abschnitten einer Messlatte, denen dann die verschieden großen Kontinente zugeordnet waren: Australien, Europa, Afrika, Amerika und Asien.

Dem Vernehmen nach soll diese Idee ganz wunderbar funktioniert haben, weshalb ich sie irgendwann auch ausprobieren möchte. Im Augenblick mache ich zwar keinen Scrum Master, für den Fall das sich das mal wieder ändert habe ich aber vorgesorgt: Ausdruckbare Flaggen gibt es hier.