09. Oktober 2020
6 Min.

#NoEstimates - Nie wieder schätzen?

Nie wieder schätzen? #NoEstimates unterstützt uns, Komplexität ohne Story Poker zu diskutieren, um wertgetriebene Produkte zu erschaffen. Ein paar Highlights des #NoEstimates-Beitrags der ModernRE2020 in Berlin...

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?
#NoEstimates. Story Points Beispiele: SP, T-Shirt Sizes, Tierarten

verschiedene Schätzmethoden, z.B. Storypoints, T-Shirt Größen, Tierarten.

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.

Erweiterte Stacey Matrix: Darstellung angelehnt an Ralph D. Stacey, Hertfordshire Business School.

Stacey Matrix: Darstellung angelehnt an Ralph D. Stacey – Anforderungs und Technologieebene, erweitert um die dritte Dimension „Menschen“.

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 auf eine Untersuchung der NASA zurückgeht. Laut dieser liegen wir zu Beginn des Projektlebenszyklus (also noch vor der Anforderungsphase) etwa um einen Faktor von 4 daneben. Das bedeutet, dass die „tatsächlich“ benötigte Zeit eines Projektes viermal so lang oder auch nur ein Viertel so lang sein kann, wie ursprünglich geschätzt.

Cone Of Uncertainty

Cone of Uncertainty: Erst nach der Umsetzungsphase erreicht die Unsicherheit 0 %.

Die Bezeichnung leitet sich aus dem zunächst stark absinkenden und sich dann der 0 annähernden Verlauf der Unsicherheits-Kurse ab. Je früher die Schätzung im Projektverlauf, umso höher ist die Unsicherheit. Sie nimmt nach und nach im Verlauf des Projektes ab und erreicht erst mit Projektende 0%. 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 %).

#NoEstimates. User Story Points vs. User Stories zählen

Vasco Duartes Chart zeigt User Story Points (orange) vs. Anzahl User Stories (grau).

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.

Novatec Chart - Verlgeich Story Points vs. Anzahl Stories

Korrelation zwischen Story Points (blau) und Anzahl User Stories (orange) in einem unserer größten Novatec-Projekte.

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

Komplexitätsmatrix von Vasco Duarte

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,…

User Story Slicing und User Story Mapping eignen sich sehr gut für wertgetriebene Produktentwicklung. Mehr zu diesen Themen findet Ihr in meinem Beitrag zum Thema User Story Mapping.

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 dich 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.

Bildnachweise: © Novatec Consulting GmbH: Schätzungen, verschiedene Varianten. © Stacey Matrix: Darstellung angelehnt an Ralph D. Stacey, Hertfordshire Business School. © Novatec Consulting GmbH: Cone of Uncertainty. Darstellung angelehnt an die Ergebnisse von Vasco Duarte und den Ergebnissen der NASA. © Novatec Consulting GmbH: Vergleich von User Stories und User Story Points. Darstellung angelehnt an die Ergebnisse von Vasco Duarte: No Estimates. How to measure project progress without estimating, OikosofySeries, 2016. © Novatec Consulting GmbH: Komplexitätsmatrix. Darstellung angelehnt an die Ergebnisse von Vasco Duarte: No Estimates. How to measure project progress without estimating, OikosofySeries, 2016.

Artikel kommentieren