Das Schätzen von Aufwänden in der Softwareentwicklung funktioniert nicht. Es funktioniert nicht in absoluten Zahlen, z.B. “Diese Features können wir in 6 Wochen umsetzen.” Und es funktioniert nicht in relativen oder verklausulierten Angaben, z.B. “Diese Features zusammengenommen bewerten wir mit 52 Story Points.”, die dann von irgendwem irgendwie in absolute Zahlen übersetzt werden.
Es funktioniert nicht. Es macht keine Freude. Es ist eine Belastung für die, die damit beauftragt werden, d.h. die Entwickler. Es sorgt für Konflikte früher oder später. Es dünnt den Kontakt zwischen Kunde und Entwicklung aus. Es ist der Qualität der Software abträglich. Und die Missweisung ist notorisch groß.
Ich kann wirklich nichts Gutes daran finden und kenne keinen Entwickler, dem das Schätzen eine Lust wäre. Hier und da gibt es POs, die behaupten, es sei nützlich — aber nach meinen Dafürhalten den Schaden nicht erkennen, der durchs Schätzen verursacht wird.
Schon lange bin ich dieser Meinung und habe in Vorträgen und Blog-Artikeln Alternativen präsentiert. Zum Abschluss meiner Beschäftigung mit dem Thema habe ich nun nochmal alle Kraft zusammengenommen und meine Sichtweise in ein Buch gegossen:
In dem Buch beschreibe ich zunächst ausführlich die Probleme, die dem gewohnheitsmäßigen Schätzen anhaften. Anschließend führe ich in kleinen Schritten in die aus meiner Sicht einzig realistische Lösung ein: das Vorhersagen.
Vorhersage, wie ich sie verstehe, unterscheidet sich fundamental vom Schätzen:
Sie basiert auf expliziten Erfahrungen in Form ausgezeichneter Lieferungen (sog. historische Daten)
und prognostiziert mittels eines nachvollziehbaren Algorithmus (sog. Monte Carlo Simulation).
Dadurch werden Prognosen erstens objektiviert und zweitens für den direkt zugänglich, der sie braucht; das sind PO, Projektleiter, Manager, Kunde. Entwickler müssen damit nicht länger belastet werden.
Für alle Vorhersagebeispiele liefere ich Typescript Code in einem GitHub-Repository mit. Wer sich also selbst daran versuchen will, ist herzlich eingeladen.
Einen Vorgeschmack darauf, wie Vorhersagen aussehen, gibt das Buchcover: Es sind Wahrscheinlichkeitsverteilungen für entweder die Gesamtdauer bis zur Lieferung einer Anzahl von Issues (oder User Stories oder Epics) oder die Anzahl der bis zu einem Termin realisierbaren Issues (oder User Stories oder Epics).
Wahrscheinlichkeitsverteilung bedeutet: Jeder Wert ist mit einer Wahrscheinlichkeit versehen. Beispiel:
Die X-Achse steht für Vorhersagen der Dauer bis zur Lieferung von 5 Anforderungen, z.B. könnte es 10 Tage oder 13 Tage oder sogar 29 Tage dauern.
Jeder Vorhersagewert hat eine Einzelwahrscheinlichkeit auf der linken Y-Achse, dass es genau so lange dauert, z.B. genau 14 Tage mit 9% Wahrscheinlichkeit oder genau 21 Tage mit 4% Wahrscheinlichkeit.
Aufsteigend sortiert haben mehrere Vorhersagewerte zusammen eine Wahrscheinlichkeit (rechte Y-Achse), dass es so lange oder kürzer dauert, z.B. 15 Tage oder kürzer mit 50% Wahrscheinlichkeit oder 20 Tage oder weniger mit 80+% Wahrscheinlichkeit.
Aus so einer maschinell erstellten Vorhersage kann sich dann ein PO aussuchen, auf welche Lieferdauer er wetten will. Entwickler müssen dafür nicht gefragt werden. Niemand muss mehr etwas auf eigentliche Schätzungen aufschlagen.
Die Planung mit Vorhersagen statt Schätzungen wird einfacher, schneller und entspannter.
Wer dieser Sichtweise — die ich nicht erfunden habe, aber zugänglicher für Entwickler darstellen wollte — eine Chance geben will oder einfach nur neugierig ist, kann das Buch bei Amazon auf Papier (oder als Kindle Version) bestellen.
Alternativ biete ich es aber auch bei Leanpub als eBook (bis Ende August 2022 mit Rabatt) an.
Viel Spaß beim Lesen! Über Feedback hier würde ich mich freuen.
Habs gekauft und gelesen, ist großartig! Habs auch meinem PO gegeben.