Fehler #1: Feste Termine als Ergebnis der Schätzung festlegen
Wann seid ihr fertig?
Wer in der Produktentwicklung tätig ist und auf diese Frage ein konkretes Datum als Antwort gibt, tut sich und seinem Team keinen Gefallen. In der Softwareentwicklung ist mehr unbekannt als bekannt und eine konkrete Zeitangabe suggeriert, dass alles nach Plan laufen wird und es zu keinen Hoppalas mehr kommen kann. Gleichzeitig bin ich Realist und Kunden und Stakeholder brauchen zuverlässige Daten für die Planung ihrer Arbeit.
Der Ausweg?
Nenne einen Zeitraum, in dem es wahrscheinlich ist, dass die Arbeit – Stand heute – fertig sein wird.
Wir nennen diese Vorhersage den „Kegel der Unsicherheit“. Hier ein Beispiel aus meinem „Professional Product Owner“-Training.
Fehler #2: Durchschnitte statt Wahrscheinlichkeiten nutzen
Eine wichtige Entscheidung steht an.
Der dreiköpfige Vorstand muss abstimmen. Ein Meeting wird auf 9:00 Uhr angesetzt. Im Durchschnitt kommt jeder der drei 5 Minuten zu spät. Wann kann die Entscheidung frühestens getroffen werden? Achtung, Falle: Dass die Entscheidung um 9:05 Uhr getroffen wird, ist unwahrscheinlich. Genauso wahrscheinlich ist, dass der CEO sich 20 Minuten verspätet. Genauso verhält es sich mit Schätzungen von Lieferterminen, die auf Durchschnitten basieren.
Schätzungen werden auch schnell zu Fallen.
Fehler #3: Nicht auf Schätzungen reagieren, sondern hoffen
Produktentwicklung ist risikobehaftet.
Es ist mehr unbekannt als bekannt. Und Schätzen ist am Ende ein Werkzeug zur Minimierung von Risiken. Damit sollen Fehler bei Kosten, Terminen und Umfängen frühzeitig erkannt werden. So weit, so gut. Was aber gefährlich ist: Bewahrheiten sich die ursprünglichen Schätzungen nicht, dann sollte nicht blind darauf gehofft werden, dass „Synergien“ magischerweise dazu führen werden, dass am Ende der Liefertermin eingehalten wird. Schätzungen sollten Teams helfen, frühzeitig den Eisberg am Horizont zu erkennen, damit sie handeln können. Hoffnung als Rezept zur Risikominimierung hat in der Produktentwicklung keinen Platz. Agilität bedeutet, aus der Realität zu lernen, um Risiken zu minimieren.
„Reagieren auf Veränderung mehr als das Befolgen eines Plans“
Daran möchte uns Agilisten auch das Manifest für agile Softwareentwicklung erinnern.
Fehler #4: Am Anfang eines Projekts schätzen
Es ist sehr verlockend, am Projektstart alles zu schätzen.
Die Aufwandsschätzung bildet die Grundlage für die Laufzeit, die Kosten und eine Prognose, was im Projekt realistisch erreichbar ist. Dieser Wunsch ignoriert nur eines: Zu Projektstart ist am wenigsten bekannt. Wie belastbar können die Schätzungen zu diesem Zeitpunkt sein? Steve McConnell, der Autor von „Software Estimation“, beantwortet die Frage mit: 25 %. Oder anders ausgedrückt:
Der Aufwand kann die ursprüngliche Schätzung um das Vierfache übersteigen.
Fehler #5: Mit „instabilen“ Teams schätzen
Was haben Magic-Estimation, Planning-Poker oder Bucket-Estimation gemeinsam?
Sie beruhen auf dem Prinzip des Vergleichs. Anstatt einem Eintrag des Product-Backlogs eine feste Größe zuzuordnen, vergleichen wir Einträge in ihrem Aufwand oder ihrer Komplexität. Was dabei übersehen wird: Der Aufwand und die Komplexität hängen auch vom Team ab. Soll heißen: Ändert sich die Zusammensetzung des Teams, ändert sich auch die Schätzung.
Umgekehrt heißt es aber auch:
Stabile Teams können sich positiv auf die Güte von Schätzungen auswirken.
Fehler #6: Schätzungen zwischen Teams vergleichen
Leider habe ich es schon miterlebt:
Es gibt Unternehmen, die die Velocity verschiedener Teams vergleichen oder, noch schlimmer, die Velocity für Teams vorgeben. Wichtig: Velocity ist das Resultat der Arbeit, die ein Team pro Sprint erledigen konnte. Die Betonung liegt auf „Resultat“. Wird eine Velocity vorgegeben, dann wird sie zum Ziel. Im besten Fall multipliziert das Team jede Schätzung von nun an mit zwei, um die vorgegebene Velocity zu erreichen. Im schlimmsten Fall lassen die Teammitglieder dafür die Kriterien, die etwas über den wirklichen Erfolg in der Produktentwicklung aussagen, wie die Kundenzufriedenheit, außer Acht oder reduzieren die Qualität, um die Velocity-Ziele zu erreichen. Wir dürfen nie vergessen: Jede Metrik wird zum Ziel.
Aber welche Ziele sagen wirklich etwas über den unternehmerischen Erfolg des Teams aus?
Fehler #7: Nur den Entwicklungsaufwand schätzen und alles andere ignorieren
Vergleiche einmal diese Zeiten:
- Durchlaufzeit: Die Zeit vom Vorschlag einer Idee bis zu dem Zeitpunkt, an dem ein Kunde tatsächlich einen Nutzen aus dieser Idee erhält.
- Zykluszeit für Kunden: Die Zeit vom Beginn der Arbeit an einem Release bis zur tatsächlichen Freigabe.
In über 10 Jahren in der Produktentwicklung habe ich noch kein Team, Projekt oder Produkt gesehen, bei dem im Verhältnis die Durchlaufzeit nicht maßlos die Zykluszeit für Kunden überstiegen hätte. Soll heißen: Die Zeit für die Entwicklung war bisher immer nur ein kleiner Anteil der Gesamtzeit von der Idee bis zur Auslieferung eines Features.
Warum schätzen dann nur die wenigsten Unternehmen die Zykluszeit für Kunden statt der Durchlaufzeit?
Fehler #8: Nicht in Automatisierung, KI und kontinuierliche Verbesserung investieren
Wie lassen sich Schätzungen verbessern?
Unter uns: Das ist eine falsche Frage. Die eigentliche Frage sollte doch lauten: Wie lässt sich Termintreue verbessern?
Wir wollen doch nicht besser schätzen, sondern termingerecht liefern. Damit ein Team termingerecht liefert, muss die Art und Weise, wie das Team arbeitet, kontinuierlich verbessert werden. Denn Entwicklung hat ein Problem, über das niemand spricht: Sie wird immer langsamer. Software altert genauso wie wir Menschen. Und wie wir Menschen den Alterungsprozess mit Sport und gesunder Ernährung verlangsamen, sollten wir es auch bei Software tun. Dort heißt es:
- Stets Handgriffe automatisieren
- Regelmäßige Retrospektiven durchführen, um die Zusammenarbeit zu verbessern
- Nach Wegen suchen, wie uns KI-Agenten bei der Arbeit unterstützen können
Willst du über Letzteres mehr erfahren?
Dann empfehle ich dir den Besuch meines „Professional Product Owner – AI“-Trainings. Dort beleuchten wir einen Tag lang, wie Scrum Teams durch den Einsatz von KI im Product-Management profitieren können.
Fehler #9: Sicherheitspuffer auf Schätzungen aufschlagen
Schätzungen sind ungenau.
Das liegt daran, dass sie mithilfe von unvollständigem Wissen getroffen werden. Manche Teams versuchen dieses Problem pragmatisch zu lösen, indem sie pauschal 20 Prozent auf jede Schätzung aufschlagen. Klingt clever. Löst aber nicht das Problem. Denn auch dieser Puffer basiert auf dem gleichen unvollständigen Wissen wie die ursprüngliche Schätzung.
Dieses Problem ist bereits in der Psychologie bekannt und wird als Planungsfehlschluss bezeichnet: Menschen unterschätzen den Aufwand für Aufgaben – selbst dann, wenn sie versuchen, ihre eigene Fehleinschätzung auszugleichen.
Verrückt, oder?
Deshalb tun Unternehmen besser daran, Schätzungen als das zu akzeptieren, was sie sind: Schätzungen.
Fehler #10: Keine Retrospektive zur Verbesserung der Schätzpraxis nutzen
„Wie können wir präziser Schätzen?“
Diese Frage wird mir häufig gestellt. Aber steht nicht „präzis“ und „schätzen“ schon im Widerspruch für sich? Der Fragende erhoffen sich jetzt eine geheime Schätzmethode, die alles auf magische weise verändert. Aber dieser Glaskugel kenne ich nicht. Was ich aber weis:
Die Güte von Schätzung lässt sich verbessern, indem wir besser schätzen lernen.
Betonung hier „lerne“ nicht „besser“. Du liest richtig. Auch schätzen kann gelernt werden. Wenn ein Team mit einer Vecoltiy von 21 pro Sprint eine User Stoies auf 8 schätzt, sie dann aber im Sprint nicht abschließen kann, dann ist diese keinen Fehler. Sondern die Möglichkeit etwas für die Arbeit uns das Schätzen im Team für die Zukunft zu lernen.
Ich glaube alles kann durch Lernen verbessert werden. Das gilt auch fürs Schätzen.
Fehler #11: Bugs und Fehler nach Aufwand schätzen
Wie lässt sich der Aufwand zur Behebung von Bugs schätzen?
Am besten gar nicht. Die meiste Zeit bei der Reparatur eines Fehlers geht nicht für die Behebung drauf, sondern für das Finden. Allerdings lässt sich der Aufwand der Behebung erst sinnvoll schätzen, wenn der Fehler gefunden ist. Und das Finden dauert so lange, wie es eben dauert. Was nun? Lieber die Auswirkung des Fehlers schätzen und dann die Kritikalität des Bugs priorisieren.
Bei kritischen Fehlern niemals Zeit in Aufwandsschätzung vergeuden, sondern diese Zeit bereits zum Reparieren nutzen.
Fehler #12: Unfertige Stories nachschätzen
Ein besonderes Anti-Pattern:
Viele Teams verändern ihre Schätzungen nachträglich. Ein Beispiel: Eine Story war mit 5 Punkten geschätzt, entpuppt sich aber als viel größer und konnte im Sprint nicht abgeschlossen werden. Nun wollen die Teammitglieder die Story im Nachhinein auf 8 oder 13 Punkte anheben. Oder die restliche Arbeit neu schätzen. Oder zwei von fünf Punkten als erledigt ansehen und noch drei in den nächsten Sprint mitnehmen.
Dieses Vorgehen birgt ein Problem:
Es untergräbt den ganzen Lerneffekt des Schätzens.
Fehler #13: Die Definition-of-Done nicht berücksichtigen
Wann die Arbeit an einer User-Story wirklich fertig ist, beschreibt die Definition-of-Done.
Dort finden sich alle Aktivitäten, die erledigt werden müssen. Etwa Code schreiben und testen, Dokumentation aktualisieren, Code-Review durchführen, in Staging deployen usw.
Schätzen Teams nur die reine Entwicklungsarbeit, ohne alle Kriterien der Definition-of-Done zu beachten, entsteht schnell etwas, das man gerne eine chronische Fehleinschätzung nennt.
Fehler #14: Immer die gleiche Schätzmethode wählen
Es gibt eine Vielzahl von Schätzmethoden.
Hier eine Auswahl: Planning-Poker, Magic-Estimation, „Buy a Feature“, Thirty-Five, Bucket-Estimation oder Value-Points.
Was hierbei aber übersehen wird: Nicht alle Methoden haben den gleichen Zweck. Also, worum geht es deinem Team beim Schätzen?
- Den Aufwand ermitteln?
- Den Wert für Stakeholder bestimmen?
- Oder gemeinsames Verständnis im Team herstellen?
Soll gemeinsames Verständnis im Team über die Arbeit im Backlog entstehen, dann würde ich Planning-Poker mit dem ganzen Team durchführen. Entwickler, Ops-Ingenieure, Tester und Designer betrachten die Arbeit aus unterschiedlichen Winkeln. Fehlen Perspektiven, entstehen schnell Risiken.
Fallen diese erst im Sprint wieder auf, kosten sie viel Zeit.
Fehler #15 Einzelne Schätzungen addieren
Nimm dir einmal die Planning-Poker-Karten zur Hand.
Lege sie nun aufsteigend vor dich hin: 0, 1, 2, 3, 5, 8, 13, 21, 40, 100. Was fällt dir auf?
- 1 plus 2 ist 3 und
- 3 plus 5 ist 8, aber
- 13 plus 21 ist nicht 40.
Das ist Absicht. Denn in der Entwicklung von Produkten ist 1 plus 1 nicht immer zwei. Es gibt Dinge, die schwierig zu berücksichtigen sind. Ein Beispiel: Die Entwicklung von Feature A ist eine 1. Die Entwicklung von Feature B ist auch eine 1. Die Entwicklung beider Features ist eine 3. Denn bei zwei Features im Produkt kommen nun auch noch Integrationstests hinzu. Und dieser Effekt verstärkt sich, je größer die Arbeit ist. Deshalb ist 13 plus 21 wahrscheinlich 40 und nicht 34.
Und den Aufwand eines Epics zu schätzen, indem alle User-Stories darin addiert werden, liefert schnell sehr falsche Ergebnisse.
Fehler #16: Epics und Stories mit der gleichen Methode schätzen
Wie schätzt man einen Epic?
Der gängige Expertenrat: Ihn zuerst aufteilen und dann die einzelnen Stories schätzen. Was Experten dann häufig übersehen: Die Stakeholder interessieren sich nicht für die Schätzungen der kleinen Stories. Sie wollen wissen, wann alle Stories fertig sind – also wann der Epic fertig ist. Alle Stories zu addieren wäre derselbe Fehler, den wir gerade besprochen haben. Was nun?
Der Ausweg ist aus meiner Sicht eine andere Skala. User-Stories in Story-Points schätzen und Epics in T-Shirt-Größen. Nicht perfekt, aber es zeigt, dass diese beiden zwei unterschiedliche Dinge sind. Und es führt hoffentlich zu einem Gespräch darüber:
Komplexität steigt nicht linear, sondern exponentiell mit der Größe.
Fehler #17: Story-Points in Tage umrechnen
Besonders neue Teams neigen dazu:
Sie rechnen Story-Points in Personentage um.
Wir können über die Sinnhaftigkeit von Story-Points gerne diskutieren. Nutze hierfür die Kommentare. Aber worüber wir nicht diskutieren sollten: Die Idee hinter Story-Points ist, den Aufwand relativ zu anderen Stories widerzuspiegeln. Es geht darum, Stories miteinander zu vergleichen. Story-Points sind keine absolute Zeiteinheit. Werden Story-Points in Personentage umgerechnet, wird die eigentlich clevere Idee, dass die Arbeit zu komplex ist, als dass genaue Aufwandsberechnungen funktionieren könnten, ad absurdum geführt.
Das ist ein No-go.
Fehler #18: Abhängigkeiten bei Schätzungen ignorieren
Warum dauert es am Ende immer länger als gedacht?
Meiner Erfahrung nach, weil nicht
- alle Abhängigkeiten,
- Unterbrechungen,
- die Kapazität oder
- Wissenslücken
berücksichtigt wurden. Genau diese Dinge führen aber dazu, dass die Schätzungen ungenau sind und Liefertermine nicht eingehalten werden. Wollen wir also, dass das Team termingerecht liefert, müssen wir Wege finden, Abhängigkeiten, Unterbrechungen, Kapazität oder Wissenslücken zu berücksichtigen.
Ich schreibe hier mit Absicht „wir“. Ich habe noch keinen Weg gefunden. Ich habe nur schmerzhaft lernen müssen, dass Abhängigkeiten jegliche Zusagen an Kunden zunichtemachen können.
Fehler #19: Auf den Ankereffekt hereinfallen
Es gibt Fehler und Fehler.
Die erste Sorte von Fehlern passiert, wenn wir uns einmalig verschätzen. Hoppala. Den Fremdservice einzubinden, war dann doch mehr Abstimmungsaufwand als gedacht.
Die zweite Sorte von Fehlern passiert immer. Mit jeder Schätzung. Wir nennen sie systematische Fehler. Ein Beispiel ist der Ankereffekt. Wenn der Product-Owner die Schätzrunde mit den Worten eröffnet:
„Die Story sollte doch in drei Tagen zu erledigen sein.“
Dann setzt er unbewusst einen Anker, an dem sich alle anderen Überlegungen orientieren. Unterbewusst sucht unser Gehirn nach Wegen, diese drei Tage möglich zu machen, und übersieht hierbei vielleicht etwas.
Dies ist der erste von drei systemischen Fehlern.
Fehler #20: Best-Case-Szenarien nutzen
Daniel Kahneman und Amos Tversky stellten fest, dass wir die Dauer von Aufgaben systematisch unterschätzen, selbst wenn wir es besser wissen.
Beim Schätzen denken wir meist an das Best-Case-Szenario. Einen reibungslosen Ablauf, keine Bugs, keine Verzögerungen, perfekt formulierte Anforderungen, keine technischen Komplikationen. Die Realität sieht aber fast nie so aus. Anforderungen ändern sich, Entwickler werden krank, unerwartete Probleme treten auf. All das blendet unser Kopf beim Schätzen aus. Er gaukelt uns ein Best-Case-Szenario vor. In Gruppen verstärkt sich dieser Effekt sogar noch. Niemand will einen guten Plan torpedieren.
Nun zum dritten systematischen Fehler:
Fehler #21: Heldenkultur fördern
Den dritten bezeichne ich liebevoll als Heldenkultur.
Ich habe dieses Phänomen schon in vielen Unternehmen beobachtet. Wer am schnellsten arbeitet, gilt als besonders kompetent. Was manchmal auch dazu verleitet, Aufwände absichtlich niedrig zu schätzen, um seine Kompetenz zum Ausdruck zu bringen.
„Was, du brauchst für diese Aufgabe fünf Tage? Pfff. Ich mache so etwas in unter drei Tagen.“
Leistungsboni und Karrierestufen sind bestimmt sinnvoll in der Bewertung der Leistung von Mitarbeitern, aber beim Schätzen können sie ungeahnte negative Konsequenzen haben.
Der Arbeitsaufwand wird unterschätzt, um als Held angesehen zu werden.