„Wie kann ich mein Team davon überzeugen, mit Story Points zu schätzen anstatt mit Manntagen?“ Abgesehen davon, dass der Begriff „Manntage“ zum Aufrollen meiner Fußnägel führt: ich werde diese Frage in diesem Blog-Beitrag nicht beantworten. Anstatt mich damit auseinandersetzen, wie man schätzt, möchte ich meine Gedanken teilen, wozu man schätzen sollte. Die üblicherweise genannten Gründe entpuppen sich bei genauerem Hinsehen als Mythos.

Schätz-Mythen

Mythos 1: Ein Team braucht Schätzungen, um eine verlässliche Vorhersage abgeben zu können, was es in einem Sprint schafft.

Ob ein Team einen Product-Backlog-Eintrag in einem Sprint umsetzen kann, hängt von verschiedenen Dingen ab: Ist das Item inhaltlich verstanden? Hat das Team eine Idee, wie die Umsetzung erfolgen soll? Gibt es Abhängigkeiten nach außen? Dies zu diskutieren, ist Sinn des Product Backlog Refinements und des Sprint Plannings. Ein arithmetischer Vergleich von Schätzwert und Kapazität deckt nur einen Teil dieser Aspekte ab. Vielleicht kommt das Team zu dem Ergebnis: „Dieses Item ist zu groß für den Sprint.“ Dann muss das Item eben weiter verfeinert werden – so lange, bis das Team die Umsetzung für möglich hält. Eine gute Praktik ist, im Refinement etwa gleich große Items zu erzeugen. Dann kann das Team ein Gefühl dafür entwickeln, wie viele dieser Items es umsetzen kann. Dies ist aus meiner Sicht der wesentliche Mehrwert einer Schätzung: sie „zwingt“ das Team, sich intensiv mit dem Item zu beschäftigen und ein gemeinsames Verständnis davon zu erzeugen.

Mythos 2: Die Product Owner:in braucht Schätzungen, damit sie einen Anhaltspunkt für die Ordnung des Backlogs hat.

Schätzungen spiegeln den Aufwand und damit die Kosten eines Product Backlog Items wieder (auch wenn immer wieder diskutiert wird, ob wir nun Komplexität oder Aufwand oder Größe oder oder oder … schätzen). Eine Kosten-Nutzen-Abwägung hört sich sinnvoll an. Dazu braucht die Product Owner:in vor allem den Nutzen. Nach meiner Erfahrung tun sich die meisten Product Owner:innen schwer damit, diesen anzugeben. Für einzelne, heruntergebrochene Product-Backlog-Einträge ist dies kaum möglich und auch nicht sinnvoll, weil der Nutzen erst durch übergeordnete komplette Features oder Epics entsteht. Wie sinnvoll ist es, Kosten-Nutzen-Abwägungen zu treffen, wenn sowohl der Nutzen als auch die Kosten reine Vermutungen sind? Vielleicht statt dessen über den Schaden nachdenken, der entsteht, wenn das Item gar nicht oder spät kommt (Cost of Delay). Oft gibt es wenige Features mit hohem Cost of Delay und viele mit geringem. Für die Product Owner:in ein klarer Hinweis, in welcher Reihenfolge Features umgesetzt werden sollten.

Mythos 3: Die Product Owner:in braucht Schätzungen, um damit einen Release Plan zu erstellen.

Ich bin der Überzeugung, dass ein Sprint-Inkrement oft zu klein ist, um wirklich Nutzen für Kunden und Stakeholder zu erzeugen. Daher bin ich ein Fan von Planungen, die über einen Sprint hinausgehen. Es gibt bewährte Möglichkeiten wie Story Mapping und Lean-Startup-Zyklen mit einem Minimum Viable Product (MVP), die darauf ausgerichtet sind, so schnell wie möglich auszuliefern. Dann erst entsteht outcome statt output und somit Kenntnis über den Nutzen. Eine auf Schätzungen basierende Release-Planung kann dagegen dazu führen, dass eine Illusion der Planbarkeit und damit der Sicherheit entsteht, die die Notwendigkeit einer schnellen Auslieferung übertüncht.

Der (verständliche) Wunsch nach Planbarkeit führt leider oft zu Machtspielchen zwischen dem (internen oder externen) Auftraggeber und der Entwicklungsabteilung. Ich habe manchmal den Eindruck, dass Termine nicht aus Notwendigkeit oder Dringlichkeit entstehen, sondern aus dem Glaubenssatz: „Ohne Druck arbeiten die Leute nicht produktiv.“ Das hört sich für mich verdächtig nach Theorie X an: „Der Mensch ist von Natur aus faul.“ Die Entwicklungsabteilung bekommt einen Release-Plan vorgesetzt oder wird genötigt, sehr frühzeitig Schätzwerte abzugeben. Sie weiß aus Erfahrung, dass realistische Schätzungen nicht akzeptiert und heftig zusammengestrichen werden. Daher baut sie verdeckte Puffer ein. Reiner Selbstschutz – aber nicht gerade eine gute Grundlage für Transparenz und vertrauensvolle Zusammenarbeit. Je mehr Politik im Spiel ist, desto schwieriger ist es, eine realitätsfernen Planung über Bord zu werfen und eine Kurskorrektur vorzunehmen. Das würde ja bedeuten zuzugeben, dass man Fehler zugeben muss! Statt dessen setzt man lieber die Entwicklung unter Druck, sich an den „vereinbarten“ Termin zu halten. Die Entwickler:innen – nicht dumm – greifen in ihre Trickkiste und produzieren schnelle, aber qualitativ schlechte Lösungen. So entstehen technische Schulden, die das Problem der mangelnden Planbarkeit langfristig vergrößern. Schlimmer noch: der durch Zeitdruck entstehende Stress verhindert Kreativität und Lernen, führt zu Frustration und manchmal sogar zu gesundheitlichen Problemen. 

Merke: Schätzungen sind kein Commitment! Ein aus Schätzungen erstellter Release-Plan ist ein Schnappschuss, der aufgrund der aktuell vorliegenden Erkenntnisse die Zukunft antizipiert – und der so schnell wie möglich auf Basis von realen Daten und neuen Erkenntnissen angepasst werden sollte. Das Agile Manifest lehrt uns: Es ist nicht das primäre Ziel, einen Plan einzuhalten, sondern Wert für Kunden und Stakeholder zu erzeugen. Dieser Wert hat manchmal mit dem ursprünglichen Plan herzlich wenig zu tun.

Mythos 4: Stakeholder brauchen Schätzungen, um zu entscheiden, ob und wieviel sie in eine Produktentwicklung investieren.

Oftmals sind frühe Schätzungen Voraussetzung für eine „Go/No Go“-Entscheidung und eine Budgetfreigabe. Sie werden zu einem Zeitpunkt erstellt (von einer PO, oder einem Projektleiter, oder einer anderen Management-Rolle), wo es noch gar kein Team gibt, das Expertenwissen einbringen könnte. Die Komplexität und Unsicherheit werden dabei geflissentlich ignoriert. Das ist kein agiles Vorgehen, sondern klassisches Projektmanagement und Wasserfall? Genau. Und genau so läuft es in vielen Unternehmen, in denen einzelne Teams nach Scrum arbeiten, aber die Randbedingungen alles andere als agil sind. Dazu gehören die Prozesse zur Budgetplanung, zu der es agile Alternativen gibt (s. Beyond Budgeting). Die Trennung von Planung und Ausführung ist die klassische Management-Arbeitsweise der Industrialisierung, die wir mit agilem Vorgehen eigentlich hinter uns lassen wollen. Eine sinnvollere Frage als die nach einem Schätzwert ist: „Wieviel Geld sind wir bereit zu investieren, bevor wir wirklich wissen, ob dieses Produkt nützlich ist?“ 

Echte Investoren für Startups agieren tatsächlich anders: Sie entscheiden, wie viel sie bereit sind, auf eine Idee zu wetten. Schafft es das Startup innerhalb eines angemessenen Anteils dieses Betrag (z.B. ein Viertel) nicht, dass Vertrauen der Investoren zu festigen, wird die Investition gestoppt – was normalerweise das Ende des Startups ist. Kann es aber aufgrund harter Daten und Fakten überzeugen, dass das Risiko geringer oder der zu erwartende Gewinn höher ist als ursprünglich gedacht, steht auch mehr Geld zur Verfügung. Und idealerweise trägt sich das Startup nach ein oder spätestens zwei Runden selbst. Die Frage lautet also nicht „Was kostet es?“, sondern „Wie viel bin ich auf der aktuellen Datenbasis bereit, zu riskieren? Und reicht das aus, um höhere Sicherheit zu gewinnen?“.

Schätzungen sind Verschwendung

Eine Schätzung ist eine Schätzung ist eine Schätzung… alle Schätzungen sind falsch, da sie – rein statistisch – mit 50%iger Wahrscheinlichkeit über- oder unterschritten werden. Die Erfahrung lehrt uns jedoch diese beiden Gesetze:

• Parkinson’sches Gesetz: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“
• Hofstadters Gesetz: „Es dauert immer länger, als man erwartet, selbst wenn man Hofstadters Gesetz berücksichtigt.“

Schätzungen können also dazu führen, dass die geschätzten Tätigkeiten sich künstlich aufblähen. Und noch schlimmer: Die Schätzungen selbst – und erst recht die Planungen mit all den beschriebenen Nebeneffekten – tragen nicht zur Wertschöpfung bei und sind daher im Lean-Sinne Verschwendung. Vor gefühlten 100 Jahren, als ich noch als Prozessverbesserin in einem Großunternehmen tätig war, gab es etliche Versuche, mit Hilfe von ausgefeilten Methoden wie „Function Points“ Schätzungen zu verbessern, oder „Historischen Daten“ so zu erfassen, dass man zukünftige Vorhaben mit vergangenen vergleichen konnte. All das war sehr aufwändig und letztendlich um so weniger erfolgreich, je innovativer die Produkte waren. 

Was also tun?

Können wir komplett auf Schätzungen verzichten und damit auch auf eine Beantwortung der Fragen: „Was kostet uns das“ und „Bis wann ist Funktion X fertig“? Wir sollten uns darüber klarwerden, ob Schätzungen wirklich das geeignete Mittel sind, diese Fragen zu beantworten. Vielleicht haben wir genug Sicherheit für einigermaßen verlässliche Schätzungen. Wenn wir jedoch keine Ahnung haben, sollten wir dazu stehen. Anstatt uns gegenseitig in die Tasche zu lügen, sollten wir die Scrum-Werte „Offenheit“ und „Mut“ beherzigen. Und gemeinsam überlegen, wie wir die Unsicherheit in den Griff bekommen können. Die agile Antwort darauf ist:

• Transparenz durch Experimente und möglichst schnelles Feedback, Inspizieren und Anpassen.  Oder in der Lean-Startup-Sprache: Build-Measure-Learn.
• An einer agilen Vision arbeiten, in der tolle Produkte mehr zählen als Planungen und wir der Realität mehr vertrauen als Schätzwerten.

Wenn ihr nach diesen Überlegungen immer noch der Überzeugung seid, dass Schätzungen sinnvoll für euch sind, können wir uns gern darüber unterhalten, wie man das (mit möglichst wenig Aufwand) macht .