Aufwandsschätzungen werden sowohl in klassischen Projekten als auch in agilen Kontexten immer wieder vom höheren Management verwendet, um die finanziellen und zeitlichen Aspekte eines vorab definierten Scopes zu bewerten:
- Was kostet der Spaß?
- Wie viele Ressourcen benötigen wir?
- Wann wird es fertig? / Sind wir im Plan?
Insbesondere agile Teams bringen andere Aspekte der Aufwandsschätzung mit ins Spiel, z.B.:
- Wie komplex ist ein Feature?
- Haben wir das gleiche Verständnis von der zu erledigenden User Story?
- Passt die Aufgabe in den Sprint?
- Wie hoch ist die Velocity (Teamkapazität), d.h. wie viele Features kann das Team je Iteration in etwa liefern?
Um Komplexität zu schätzen setzen agile (sowie zunehmend auch klassisch aufgestellte) Teams Methoden wie das Planning Poker ein. Dabei bewerten einige Teams in Storypoints, andere bewerten in T-Shirt-Größen, Tierarten oder in anderen Maßen. Demnach liegt der Zweck des Planning Pokers nicht in der Aufwandsbewertung der Features.
Ziel des Planning Pokers ist der Austausch über die einzelnen Aufgaben: Das Team möchte ein gemeinsames Verständnis über die zu bewältigenden Aufgaben schaffen, sorgt somit für Transparenz und minimiert Risiken, die auf Unstimmigkeiten basieren.
It’s an estimate, not an exactimate.
Leider kommt es immer wieder vor, dass das Management diese Schätzungen in PT umrechnet. Nach meiner Erfahrung gehen einige Unternehmen sogar soweit und verknüpfen eine Preisliste mit den geschätzten Storypoints. Die Entwickler werden demzufolge nach Storypoints bezahlt. Die errechneten PT werden dann als Deadlines behandelt.
So kann das aus meiner Sicht nicht funktionieren, denn wir sprechen nach wie vor von einer Schätzung und nicht von Gewissheit.
Ursachen
(Aufwands-) Schätzen funktioniert oft nicht. Dies liegt daran, dass wir in einer komplexen Welt leben. Um die Dimensionen von Komplexität besser zu verstehen hilft uns das Stacey Modell weiter. Dieses zeigt, dass Komplexität von Unsicherheiten auf Technologie- und Anforderungsebene geprägt ist. Dieses Umfeld beherrschen wir nicht. Stattdessen befinden wir uns in einem stetigen Lern- und Entdeckungsmodus. Jede dieser Dimensionen wirkt sich auf die Komplexität aus.
Je klarer die Anforderungen und je bekannter die Technologie involviert sind, desto simpler ist also das Vorhaben. Solche Projekte eignen sich gut für das klassische Projektmanagement, z.B. das Wasserfall-Modell. Je unklarer die Anforderungen und Technologien und je mehr Personen beteiligt sind, desto komplizierter oder auch komplexer wird es.
Das Ganze lässt sich auch auf die Entwicklung von Softwareprodukten übertragen: Wenn Firma A und Firma B durch den selben IT-Dienstleister betreut werden, und Firma A beauftragt ihn das gleiche Produkt 1:1 nachzubauen wie Firma B es bereits in Produktion hat, dann gibt es dennoch Unsicherheiten, z.B. andere Systemschnittstellen, andere Version, andere Stakeholder oder firmeneigene Sonderimplementierungen, die das Vorhaben in eine komplexe Dimension verlagern. Daraus folgt, dass ich erst am Ende des Projektes mit 100%iger Sicherheit Aussagen über die Dauer und Kosten treffen kann.
Dass der Zeitpunkt einer Schätzung entscheidend ist, veranschaulicht der Cone of Uncertainty, welcher aus einer Untersuchung der NASA hervorgeht: Betrachten wir den gesamten Projektlebenszyklus liegen Schätzungen bereits vor der Anforderungsphase etwa um einen Faktor von 4 daneben. Ist eine Prognose mit einem Faktor von 4 belastet bedeutet dies, dass ein Projekt etwa viermal länger oder eben nur ein Viertel so viel Zeit benötigt, wie zunächst geplant.
Je früher die Schätzung im Projektverlauf stattfindet, umso höher ist die Unsicherheit. Während eines Projektes werden nach und nach neue Erkenntnisse gewonnen, sodass die Unsicherheit absinkt und sich der immer mehr der 0 annähert. Ich kann also erst nach Projektende eine 100%ig richtige Aussage über die Dauer und entstandenen Kosten treffen. Eine Schätzung zu Beginn liefert mir allenfalls einen groben Anhaltspunkt. Es ist daher sinnvoll, den Projektplan regelmäßig zu aktualisieren. Um die Unsicherheiten in den Projektplan regelmäßig einfließen zu lassen, kann die Zwei-Zeiten-Methode oder auch die Drei-Zeiten-Methode verwendet werden. Dennoch bleibt es bei einer Schätzung.
#NoEstimates
Wenn Schätzungen uns also nur einen groben Anhaltspunkt liefern, warum dann überhaupt schätzen? Das fragte sich auch Vasco Duarte, der die #NoEstimates Bewegung sehr stark vorangetrieben hat. In seinem Buch beschreibt er seine Grundgedanken und verweist dabei auch u.a. auf Hofstadter’s Law:
„It always takes longer than you expect, even when you take into account Hofstadter’s Law.“ – Douglas Hofstadter
#NoEstimates in 3 Grundgedanken zusammengefasst:
1. Man braucht keine Story Points oder Schätzung, um Planungen und Teamkapazität zu ermitteln
Vasco fand heraus, dass ihn das Schätzen von User Stories und das Zählen von User Stories zu einem sehr naheliegenden Ergebnis führt (Toleranz 15 %).
Und tatsächlich: Angewandt auf eines der größten unserer Projekte ist erkennbar, dass die Velocity basierend auf der Anzahl der Stories mit den in der Iteration gelieferten Storypoints korreliert. Das bedeutet, ich kann meine Planung auf Basis der gelieferten Storyanzahl erstellen und spare mir, zeitlich betrachtet, das Pokern.
2. Man kann die Risiken anders identifizieren
Verzichtet man auf das Story Poker, verzichtet man automatisch auch auf den Austausch über die Komplexität und riskiert, kein gemeinsames Verständnis von den zu erledigenden Aufgaben im Team zu schaffen. Das erhöht das Risiko und gefährdet den Projekterfolg. Um dieses Dilemma zu lösen, erarbeitete Vasco das Konzept der Komplexitätsmatrix. Die Komplexität jeder User Story soll anhand von zwei Dimensionen bewertet werden:
- Soziale Komplexität
- Technische Komplexität
Daraus ergeben sich 4 Quadranten, die auch jeweils klar definierte Maßnahmen erfordern. Anstelle eine User Story zu schätzen, platziert das Team die Story auf der Matrix. Daraus entsteht eine fundiertere Diskussion, die für Transparenz und ein gemeinsames Verständnis sorgt.
3. Man sollte sich auf den Value fokussieren, nicht auf die Features
Wird Story Poker durch das Zählen von Stories ersetzt, sollte der wichtigste Aspekt der Produktentwicklung nicht untergehen: Das Generieren von Impact. Das Wichtigste überhaupt ist es sich auf den erwarteten Mehrwert der neuen Features zu fokussieren. Es geht nicht um die Anzahl der neuen Features, sondern darum, welche Auswirkungen sie erzielen sollen. Wir erfinden das Rad meist nicht neu, sondern wir machen Dinge schneller, besser, erreichbarer, einfacher,…
Herausforderungen bei der Einführung von #NoEstimates
#NoEstimates stellt uns vor neue Herausforderungen: Veränderungen werden i.d.R. von vielen Mitarbeitern und Führungskräften abgelehnt, denn sie bedeuten das Betreten eines neuen Terrains. Dies bedeutet Unsicherheiten und Risiken. Dennoch können die Hindernisse bei der Einführung von #NoEstimates überwunden werden:
Zunächst ist es sinnvoll, soviel und so oft wie möglich zu erklären. Dabei hilft es uns, Unterstützer zu identifizieren und einzubinden. Das Management, dass auf Zahlen für die Planung von Zeit und Budget pocht muss überzeugt werden, indem man die bisherigen Fragen durch die richtigen Fragen tauscht,
- z.B. nicht „Was soll es kosten?“, sondern „Was soll es bringen und wieviel bist du bereit zu investieren?“
- z.B. nicht „Passt die User Story in den Sprint?“, sondern „Ist die Story nach Wert geschnitten?“
Auch das Team muss den richtigen Reifegrad erreicht haben, und sein Mindset möglicherweise ändern. Interessiert sich das Team für den Produkterfolg – anstatt nur kommentarlos eine Liste an Features abzuarbeiten – dann ist es auch in der Lage den Mehrwert und Sinn von Features zu hinterfragen, Alternativen anzubieten oder bei Bedarf auch mal „nein“ zu sagen.
Darüber hinaus ist es wichtig, dass die Rolle des Product Owners im Unternehmen richtig verstanden wurde. Der Product Owner muss seine Rolle richtig leben dürfen. Dafür benötigt er Durchsetzungsfähigkeit und Empowerment (durch das Management). Als Verantwortlicher für die Produkt Vision ist er die Schnittstelle zu den Stakeholdern und ist befähigt die finalen Entscheidungen selbst zu treffen. Der Product Owner muss dem Team vertrauen können und sollte keine Lösungen vorschreiben bzw. sich nicht in Schätzungen oder Lösungen einmischen. Um Stories im Rahmen von #NoEstimates richtig zählbar zu gestalten und je Iteration für Impact zu sorgen gehört es zu den wichtigsten Aufgaben des Product Owners, User Stories nach Mehrwert zu schneiden und zu priorisieren. Ziel ist es, kleinere planbare und testbare Arbeitspakete zu schnüren. Das User Story Slicing fasst im Endeffekt alle Überlegungen und Dimensionen zusammen, die für den Erfolg der umgesetzten Features notwendig sind:
- Fokus auf den Impact / Value
- Unnötige Features / Aufwände vermeiden
Unterstützung zum Thema Product Ownership findet Ihr in unserem Beratungsangebot sowie in unserem Trainingsangebot.
Fazit
- Erst nach Projektabschluss sind Dauer und Kosten zu 100%ig eindeutig. Der Projektplan muss stetig aktualisiert werden. Unsicherheiten können durch die Zwei- bzw. Drei-Zeiten-Methode beim Aktualisieren des Plans miteinkalkuliert werden.
- Aufwandsschätzungen sind weiterhin allenfalls ein grober Anhaltspunkt.
- Story Poker schätzt Komplexität, und nicht den Aufwand.
- #NoEstimates ersetzt Storypoints durch die Anzahl von Stories, um auf die Velocity zu schließen.
- #NoEstimates bietet die Komplexitätsmatrix, um Komplexität zu diskutieren.
- #NoEstimates setzt den Mehrwert und Impact in den Fokus, nicht das Scope.
- Um #NoEstimates einzuführen, müssen die richtigen Fragen gestellt werden, das Team muss das richtige Mindset mitbringen und der Product Owner muss seine Rolle ausleben dürfen.
Quellen
Vasco Duarte: No Estimates. How to measure project progress without estimating, OikosofySeries, 2016.
Anis Ben Hamidene, Katharina Hersztowski: #NoEstimates. Nie wieder schätzen!, ModernRE, Berlin, 10/2020.
