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

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

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

  • 19. Mai 2017 um 22:50
    Permalink

    Schöne Zusammenfassung. Ich kann dem nur zustimmen. Unser Cross-Funktionales-Team hatte eine berechnete Velocity von ca 32 Storypoints wobei wir immer auf 3 bis max 5 gesliced haben. Dennoch war jeder Sprint mit mind. 70 SP vollgepackt. Denn was offen war … wartet ja nur auf den release prozess (Apple Review, Android gestaffelter Release). Jedes Planing / Refinement war eine qual. Alte Tickets mussten erneut besprochen werden. Diskussionen ob die SP angepasst werden sollten oder nicht. Jedes Burndown Diagramm ähnelte mehr einer Stadt-Siluette. Unser Team hat sehr lange gekämpft auch mit verschiedenen Methoden. Aber leider haben wir es nicht geschaft.

    Antworten
    • 23. Mai 2017 um 21:34
      Permalink

      Hallo Mario,

      danke für deinen Input! Ich denke, externe Abhängigkeiten spielen in den meisten Teams eine Rolle und das Team muss dann Lösungen dafür finden. Im Beispiel von cross-Plattform App-Entwicklungsteams ist es mitunter ziemlich extrem, da jedes cross-funktionale Team für so viele verschiedene Plattformen liefert. In Scrum und Kanban kann dafür eine Definition Of Done ein Lösungsansatz sein. Jedoch finde ich, dass Kanban generell die Transparenz über die Abhängigkeiten besser hinbekommt als etwa Scrum.

      Die erneute Besprechung von Tickets und das Neuschätzen brachte Paul Klipp mal auf Twitter reißerisch auf den Punkt:

      „Most backlogs are waste. Estimating backlog items is therefore super-waste. Revising backlog estimates are in mentally-deranged territory.“

      Ich bin schon fast mit Teil 2 des Artikels fertig. Dort geht es dann z.B. um #noestimates und Kanban. Stay tuned! 🙂

      Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.