Schätzungen von Scrum über #Noestimates zu Kanban – Teil 1

Anja und ich haben vor einer Weile wieder das agiLE Meetup in Leipzig besucht. Diesmal gab es ein Fokusthema, “Product Ownership”, und so behandelte eine Session des Open Space auf dem Meetup die Frage, welche Schätzverfahren die Teilnehmer in ihren Teams einsetzen und ob denn überhaupt geschätzt wird. Das Thema wird auch im Management 3.0, in der #noestimates-Initiative, in Scrum 3.0 und in Kanban angesprochen, was ich in diesem Doppel-Artikel etwas genauer unter die Lupe nehme.

Schätzmethoden

Die meisten agilen Teams starten mit Scrum und viele Teams adaptieren schnell ein Schätzverfahren – etwa mit Story Points nach Fibonacci-Zahlen in Planning-Poker-Runden.

Betrachtet man nun über die Zeit viele Teams, so findet man Abwandlungen und Vereinfachungen davon. Insbesondere am Anfang tun sich viele Teams, die aus einer klassischen Projektmanagementwelt kommen, schwer mit abstrakten Größen wie Story Points. Sie schätzen daher gern in Zeitangaben mit Stunden oder Tagen – oder sie haben eine Umrechnung in Story-Punkte. Gerade wenn ein Team noch keinen leicht von der Hand gehenden Schätzprozess hat, lohnt sich auch der Einsatz von Referenz-Stories, die eine Art Skala für Schätzungen vorgeben.

Anderen Teams sind die Story-Punkte zu granular – sie brauchen viel Zeit zum Schätzen, ziehen aber gar nicht so viel nützliche Informationen daraus. Diese Teams legen sich dann z.B. auf nur wenige mögliche Größenkategorien fest – “alles größer als 8 ist zu groß”. Oder aber sie gehen zu einfacheren Systeme über und schätzen in T-Shirt-Größen mit S, M, L.

Foto: Rolf Irion

Mit Planning Poker werden die einzuschätzenden User Stories zwar so besprochen, dass jeder ihren Sinn und Kern verstanden hat, jedoch spricht man jede Story durch – und das kann recht viel Zeit in Anspruch nehmen. Viel schneller kann hier Magic Estimation sein, denn hier bespricht man nur die Stories, die noch Klärung benötigen. Ich habe Teams gesehen, die damit in 45 Minuten satte 50 Tickets geschätzt haben (ok, hier waren nicht nur User Stories sondern auch Verbesserungen und Defekte dabei).

Auf dem Meetup in Leipzig brachte ein Teilnehmer eine mir noch unbekannte Technik mit: 3-Punkte-Schätzung nach DeMarco. Diese ist ein recht technischer, mathematischer Ansatz aus Best-case, Worst-case und resultierender realistischer Schätzung.

Bereits 2014 habe ich einmal versucht, unseren Product Ownern die verbreiteten Schätzmethoden in einer Grafik gegenüberzustellen:

Sind denn aber Schätzungen überhaupt nützlich und nötig? Neben dem schon erwähnten Zeitaufwand können sich auch weitere Nachteile offenbaren.

Management 3.0

Jurgen Appelo zeigt in seinem Management 3.0 Workout ein grundlegendes Problem von Metriken auf, insbesondere, wenn diese außerhalb des teaminternen Kontextes verwendet werden.

Und er beschreibt mit dem “Hawthorne Effect” auch einen psychologischen Aspekt: Wenn die Produktivität einer Person gemessen wird, dann legt diese Person mehr Aufmerksamkeit auf ihre Arbeit und die Produktivität steigt. In anderen Situationen kann es aber anders herum sein. Ein Qualitätstest am Ende der Produktionslinie kann eine Aufmerksamkeit für Sicherheit so erhöhen, dass Arbeiter mehr Risiken eingehen und dadurch die Qualität sinkt (Denn “wir haben ja den Test, der wird die Fehler schon finden”).

Bezogen auf Schätzungen schreibt Appelo: Der Versuch, die Größe eines Projektes abzuschätzen führt dazu, dass die Leute mehr Anforderungen hinzufügen – wodurch die Schätzung nach oben geht. Neben einer daraus geschlussgefolgerten Regel “Misstraue allen Zahlen” fand ich eine zweite Regel auch sehr treffend: “Sei selbst Herr über deine Metriken”.

Die Teams, die ich über die Zeit beobachtet habe, sind oft bzgl. ihrer Metriken stark von außen gesteuert und haben deshalb so viel Frust und Zeitaufwand damit. Es wird erwartet, dass sie ihre Velocity steigern, oder dass sie ein Backlog “durchpokern”. Dabei lohnt es sich, das Spiel herum zu drehen. Ein Team kann seine Metriken selbst beherrschen und bestimmen. Allerdings muss man ihnen vorher das “Warum” vermitteln. Sie müssen die Grundidee verstanden haben, warum man die Schätzungen durchführt und welchen Nutzen sie damit haben.

Im zweiten Teil des Artikel gebe ich einen Überblick über #Noestimates, Scrum 3.0 und Kanban. Diese beschreiben alternative Ansätze, wie Teams sich einfacher in Eigenregie messen können.

Quellen

• Metrics Ecosystems in Managing for Happiness – Games, Tools and Practices to Motivate Any Team (vormals das “Workout”-Buch), Management 3.0, Jurgen Appelo, https://management30.com/product/managing-for-happiness/
• How Metrics Can Be Used and Abused by Management, Management 3.0 Practices: Metrics Ecosystem, Jurgen Appelo, https://management30.com/product/workouts/metrics-ecosystem/
• 3-Punkt-Schätzung, Wikipedia, https://de.wikipedia.org/wiki/Drei-Zeiten-Methode
• Magic Estimation, David Campey, http://campey.blogspot.de/2010/09/magic-estimation.html
• Agile Leipzig, Meetup, https://www.meetup.com/agileipzig/?_locale=de-DE