Die Risiken der Zeitschätzungen

in agilen Teams und was sind die Alternativen?

Inhaltsverzeichnis

Zeitschätzungen sind ohne Zweifel eine dieser Fragen, die die agile Gemeinde in zwei Lager teilt. Stark vereinfacht sind die meisten Entwickler-Teams dagegen, während das Management oft darauf besteht. Beide haben ihre Gründe und meist sind diese auch auf beiden Seiten ziemlich naheliegend und nachvollziehbar.

Entwicklerteams bestreiten regelmäßig den Sinn dieser Übung und fühlen sich zudem auch noch unrechtmäßig kontrolliert oder gar ge-micromanaged. Organisationen betonen hingegen gerne ihr ureigenes Interesse nach Handlungsfähigkeit durch Planbarkeit, sowohl bezüglich Time-to-Market als auch bezüglich Budgets und Kosten.

Selbstverständlich und wie könnte es auch anders sein, haben beide recht und lassen es sich gegenseitig auch besonders gerne wissen. Im unermüdlichen Bemühen um eine gute Lösung wird – auch das ist keine Überraschung – das Problem in die Methodik und damit zu Agile Coaches und/oder Scrum Mastern verschoben. Sie sollen nun dem jeweils anderen die Position erklären, bzw. sie bei der Gelegenheit auch gleich vom jeweiligen Gegenteil überzeugen.

Das ist manchmal gar nicht so einfach – ebenfalls aus naheliegenden Gründen – und daher widme ich diesem Thema diesen kurzen Artikel mit einer klaren und Eindeutigen Empfehlung, die hoffentlich beide Seiten verstehen und akzeptieren können.

Um einem großen Missverständnis vorzubeugen, in diesem Artikel geht es um die Schätzung des Aufwandes in Zeit. Es geht hier nicht um die Schätzung der job-size in Story Points. Beides wird leider zu oft verwechselt, meist in dem Sinne, dass Story Points als Währung für Aufwandsschätzungen verwendet wird. Oft auch, weil Akteure den Unterschied zwischen job-size und Aufwand nicht wirklich reflektieren. Wie kann man sie unterscheiden? Mehr dazu ein bisschen später…

Aber zurück zu unserer Aufwandsschätzung bzw. Zeitschätzung. Beide Begriffe verwende ich hier synonym.

Für alle, die genauso ungeduldig sind wie ich, gebe ich die Antwort gleich nach der Werbung… ähhhh… nein, ich gebe sie heute ausnahmsweise sofort und anschließend für alle, die es genau wissen wollen, oder denen die Antwort nicht gefällt, gebe ich die Begründung.

Einverstanden?

Ich werte das Schweigen mal als ein „ja“.

Sind Zeitschätzungen in Agile effektiv?

Zeitschätzungen für PBI‘s (Product Backlog Items) – also in der Regel Storys – oder auch für Subtasks sind…

Nutzlos.

Sie bringen nicht das, was man gerne hätte, und mit etwas Pech bringen sie Teams und Organisation sogar noch etwas weiter weg von dem, was man eigentlich erreichen möchte.

Ich sage nicht, dass sie nicht nützlich wären, wenn sie funktionieren würden, aber sie tun es einfach nicht und daher passiert oft das Gegenteil von dem, was man gerne hätte. Dazu komme ich gleich noch.

Allen, denen die Antwort reicht, können hier aufhören zu lesen. Diese Meinung werde ich nachfolgend auch nicht relativieren. Alle, die wissen wollen warum, oder begründete Zweifel an meiner Hypothese haben, sollten unbedingt weiterlesen.

Vor- und Nachteile von Zeitschätzungen

Ich gebe zu, vor noch gar nicht allzu langer Zeit habe ich genau das Gegenteil behauptet. Ich gehörte auch zur Fraktion der Zeitschätzer, habe das regelmäßig in meinen Trainings gefordert und auch begründet, warum sie so wichtig sind. Ich unterlag dem Schicksal von (Selbst)Reflektion und Erfahrung.

Je länger ich mir das angesehen habe und darüber nachgedacht habe, desto weniger finde ich, dass Zeitschätzung eine Lösung für das Problem des agilen Forecastings sein kann. Heute also nehme ich alles zurück und behaupte das Gegenteil und entschuldige mich aufrichtig und ausdrücklich bei allen, denen ich mit den Zeitschätzungen auf die Nerven gegangen bin.

Aber der Reihe nach. Warum war ich ein Freund der Zeitschätzung und warum sind es – berechtigterweise – heute noch immer viele Projektmanager, Product-Owner, Business-Owner und Stakeholder?

Warum sind oft Zeitschätzungen unzureichend?

Zeitschätzungen helfen Teams, sich zu committen

In meinen Trainings zitiere ich zwei Grundwerte agiler Arbeitsweise: Commitment und Completion. Hier geht es vor allem um das Commitment. Es lässt sich im KPI „Sprint Accuracy“ ganz gut ablesen. Die sehr verkürzte Begründung dafür ist folgende:

Commitment: wir als Team nehmen uns für einen Sprint etwas vor und genau das liefern wir auch. Wenn das regelmäßig nicht gilt, braucht man keine Sprints mehr – kann also gleich zu Kanban übergehen – und nimmt damit einer Organisation jede Chance irgendeine halbwegs valide Planung machen zu können. In Zeiten von Time-To-Market ist das gar nicht gut.
Die ausführliche Begründung habe ich im Artikel „Die 4 C’s“ gegeben.

Es ist schon naheliegend, dass zum Herstellen eines Commitments Zeitschätzungen auf Basis von Subtasks ziemlich hilfreich sind, wenn nicht sogar alternativlos erscheinen. Denn ein Sprint ist nun mal eine Timebox, also alles, was ich darin tue, hat eine zeitliche Komponente. Anders als im klassischen Projektmanagement (z.B. Wasserfall), wo sich die Länge der Phasen nach den Inhalten richtet, ist es im agilen Context eben genau umgekehrt, fast alles ist timeboxed. Das ist nun mal die DNA agiler Methodik. Da kann man dann schlecht sagen, soooo wichtig ist die Sprint Accuracy bzw. das Einhalten des Commitments nun auch wieder nicht.

Zeitschätzungen nicht gut- bzw. nicht hilfreich zu finden, ist also gar nicht so einfach. Denn Commitment möchten wir eigentlich nicht absagen und zurück zum Phasenmodell, also zurück zum klassischen Projektmanagement wollen wir auch nicht.

Contra: Wir können Zeit schlecht einschätzen

Das Problem ist leider, dass Zeitschätzungen schlicht nicht funktionieren, sie führen nicht zu dem Ergebnis, das wir haben möchten, so sehr sich Entwicklerteams auch bemühen. Ich habe diesen Umstand viel und lange mit sehr erfahrenen Entwicklern, Architekten, Trainern, CTO’s, – you name it – diskutiert. Und ich habe es auch mit unerfahrenen Entwicklern diskutiert, die ja eben auch Teil der Teams sind und sie gefragt, was sie denken, was sie bräuchten, um valide Zeitschätzungen abgeben zu können.

Das waren sehr intensive Diskussionen, denn immerhin bin ich nicht nur agile Coach, sondern auch selbst Business Owner für unser Produkt (Achtung Werbeblock: https://scagile.io ) und habe ein ziemlich hohes Interesse daran, dass Commitments eingehalten werden.

Zudem haben wir unzählige Sprints in unterschiedlichsten Projekten analysiert, inwieweit die Schätzungen mit den Zeitbuchungen übereinstimmen. Das Ergebnis war ernüchternd. Dabei haben wir alles versucht, wie z.B. Subtask klein zu halten, also unter 4 Stunden, weil man kleine Dinge nun mal präziser schätzen kann als komplexe Gegenstände. Dennoch, die Abweichungen waren ungefähr so groß, als hätten wir einfach gewürfelt und dabei festgestellt, dass wir nicht gerade eine Glücks-Strähne haben.

So wichtig die Zeitschätzungen auch wären und so gerne wir sie hätten – beides Konjunktive -, wir kommen einfach nicht dicht genug an ein brauchbares Ergebnis.

Selbst sehr erfahrene Entwickler haben mir bestätigt, dass sie bei einer hinreichenden Komplexität einer Aufgabe, keine präzise Schätzung mehr abliefern können. Es sind schlicht zu viele Faktoren, die dafür eine Rolle spielen – bis hin zur Tagesform – die sich nicht alle einschätzen oder gar ausklammern lassen. Es ist, als ob man eine Landkarte im Maßstab 1:1 bräuchte.

Einige kommentieren dazu, dass war ja gerade der Grund der Entwicklung von Extreme-Programming und anderen Techniken, als Vorläufer agiler Methodik, weil Dinge – ähnlich wie kreative Prozesse – zu komplex wurden, um planbar zu bleiben. Ein Teufelskreis.

Gibt es eine Alternative zur Zeiteinschätzung?

Natürlich haben wir als Antwort darauf, Techniken zur Reduktion von Komplexität und Dekomposition entwickelt, aber sie führen nicht so weit, dass Subtasks zeitlich valide schätzbar sind. Es hilft nichts, wir müssen dieser Tatsache ins Auge sehen.

Die Idee, Zeitschätzungen alternativlos gegenüberzustehen bei gleichzeitigem Einsehen, dass sie aber nicht funktionieren, löst bei einigen eine Menge Frustration aus. Und doch, oder gerade deshalb müssen wir uns die Frage stellen, wie wir aus diesem Dilemma herauskommen. Vielleicht ist es gar nicht so schlimm, wie es aussieht.

Was wir brauchen, ist ein Umdenken. Statt Zahlen, also Zeitschätzungen zu vertrauen sollten wir unserem Setup vertrauen lernen. Das sind wir so nicht gewohnt und es erfordert ein Stück weit mehr Mut. Aber betrachten wir es richtig, kommt am Ende sogar noch mehr Agilität und ein besseres Verständnis agiler Arbeitsweise heraus und wir hätten am Ende sogar mehr gewonnen als nur eine gute Einschätzung unserer Lieferfähigkeit.

Jetzt aber mal konkret. Wie oben erwähnt ist Commitment einer von zwei Grundwerten agiler Methodik. Das bleibt auch so. Was aber ist der Zweck agiler Methodik? Zweifellos ist der Zweck agilen Arbeitens die Herstellung von Business Agility, also der Fähigkeit von Organisationen schnell auf sich ändernde Marktsituationen reagieren zu können.

Dazu benötigt die Organisation vor allem einen

Flow von Value. 

Business Agility und Flow von Value sind zwei Seiten einer Medaille. Jedes Team, jede Organisation sollte also darnach streben, Flow zu erzeugen. Dazu sollte man – wo irgend möglich – alle Flow-verhindernde Dinge genau auf den Prüfstand stellen und wenn irgend geht eliminieren.

Contra: Zeitschätzungen lenken uns von wichtigeren Diskussionen ab

Zeitschätzungen sind definitiv eine Flow-verhindernde Übung. Das ist die zweite wichtige Erkenntnis, die wir aus unseren Gesprächen und Beobachtungen gewonnen haben. Zeitschätzungen führen zu oft zu kleingeistigen Diskussionen, sie konterkarieren geradezu die wertvollen Diskussionen um den Sinn von Features und die Wege, sie zu implementieren.

Konkret gesagt, Teams vermeiden, einen detaillierten Implementierungsplan zu erstellen, wenn über ihnen das Damoklesschwert der Zeitschätzung schwebt. Je konkreter sie werden, desto öfter müssen sie die ungeliebten Schätzungen machen und desto mehr wird über die Form statt über die Inhalte diskutiert. Denn auch im agilen Planungsprozess sind die Timeboxes nicht beliebig ausdehnbar.

Einem Team, das wirklich im Flow ist, würde ich in Bezug auf Commitment letztlich mehr vertrauen, als einem Team, dass krampfhaft und mit viel Aufwand versucht, Zeitschätzungen zu machen, von denen nach einiger Zeit eh alle wissen, dass sie nicht gut funktionieren und alle Akteure am Ende als Enttäuschte zurücklässt.

Was sind nochmal Story Points und wie unterscheiden sie sich von Zeitschätzungen?

Daher an dieser Stelle noch ein paar Worte zur Unterscheidung. Das ist wichtig, denn die Bewertung welche Schätzung nützlich ist und welche nicht, fällt gleich sehr unterschiedlich aus. Die Formel für Job Size, die sich inzwischen weitgehend durchgesetzt hat ist:

Job Size = amount of work + complexity + uncertainty

Hier ein kurzes Beispiel, welches den Unterschied zwischen job-size und Aufwand illustriert. Sie sollen im Winter vor Ihrer Haustür den Weg vom Schnee befreien. Das Beispiel ist etwas weit hergeholt, da wegen des Klimawandels Schnee eher selten geworden ist, aber einige werden sich vielleicht noch mit unguten Gefühlen an das Schneeschaufeln erinnern. Sie sollen nun den Aufwand schätzen, Ihr(e) Lebenspartner(in) fragt Sie, wann Sie damit fertig sein werden. Hier ist also eine simple Aufwandsschätzung in Zeit – also eine Zeitschätzung – gefragt. Intuitiv werden sie diese Schätzung in zwei Schritten erstellen.

Schritt 1: Sie schätzen die Job Size und wenden dazu die oben genannte Formel an

Amount of work
↪︎
Wie viel Schnee muss überhaupt weggeschaufelt werden? Sagen wir mal es sind 20 cm Neuschnee gefallen, der Weg ist 20m lang und 4m breit.
Complexity
↪︎
Eskimos kennen ca. 200 verschiedene Worte für Schnee. Schnee ist also nicht gleich Schnee und wenn sie Pech haben, ist der Schnee unten bereits zu Eis geworden. Die Sache wird also komplexer. Vielleicht ist es aber auch nur leichter Pulverschnee, den noch keiner festgetreten hat und sie können statt einer Schaufel oder eines Spatens einen Schneeschieber verwenden.
Uncertainty
↪︎
Sie schauen nach oben in den Himmel und stellen fest, das sieht schon wieder so aus, als ob es gleich nochmal schneien könnte. Sie wissen es nicht so genau, Ihre Wetter-App sagt eine 70%ige Wahrscheinlichkeit. Wenn es schneit, wir die job size unweigerlich größer.
Amount of work
↪︎
wieviel Schnee muss überhaupt weggeschaufelt werden? Sagen wir mal es sind 20 cm Neuschnee gefallen, der Weg ist 20m lang und 4m breit.
Complexity
↪︎
Eskimos kennen ca. 200 verschiedene Worte für Schnee. Schnee ist also nicht gleich Schnee und wenn sie Pech haben, ist der Schnee unten bereits zu Eis geworden. Die Sache wird also komplexer. Vielleicht ist es aber auch nur leichter Pulverschnee, den noch keiner festgetreten hat und sie können statt einer Schaufel oder eines Spatens einen Schneeschieber verwenden.
Uncertainty
↪︎
Sie schauen nach oben in den Himmel und stellen fest, das sieht schon wieder so aus, als ob es gleich nochmal schneien könnte. Sie wissen es nicht so genau, Ihre Wetter-App sagt eine 70%ige Wahrscheinlichkeit. Wenn es schneit, wir die job size unweigerlich größer.

Die job size beschäftigt sich also mit dem Gegenstand selbst, ist also völlig unabhängig davon, ob Sie das machen, oder Ihren Kindern den aus deren Sicht völlig unverdienten Hausarrest erlassen, wenn sie den job übernehmen.

Schritt 2: Jetzt schätzen Sie den Aufwand

Und dieser ist natürlich stark davon abhängig, wer es tut. Ein starker König wird länger brauchen als die sieben Zwerge. Anzahl der Arbeiter (oder knowledge-worker wie es in Neudeutsch heißt), Fähigkeiten, Erfahrung, Werkzeuge, Methode, Motivation, etc. – all das hat Einfluss auf den Aufwand. Während also job size eher auf die Beschaffenheit des Gegenstandes weist, weist der Aufwand eher auf die Eigenschaften des Teams, also der Personen.

Für den Aufwand gibt es die natürliche Währung Zeit. Zur Bestimmung des Aufwands machen wir also eine Zeitschätzung, natürlich in Relation zur job size. Alles andere macht eigentlich keinen Sinn. Wenn Ihnen die Frage gestellt wird, „Wann sind Sie fertig?“, könnten Sie bestenfalls den Frager mit der Antwort „In 13 Story Points.“ verblüffen. Sehr hilfreich wird der Frager die Antwort wohl nicht finden, es sei denn, er kennt genau Ihre Velocity. Aber die würde er auch gleich in Zeit umrechnen, den Umweg könnte man sich dann gleich sparen.

Für job size gibt es keine Währung. Das liegt vor allem an dem Bestandteil „Komplexität“ in der Formel. Wir beschäftigen uns sehr viel mit Komplexität in der Welt, aber eine Skala wie zum Beispiel Fahrenheit und eine Messmethode hat die Welt noch nicht erfunden.

Meines Wissens nach ist die Währung Story Points, selbst in der Form (team/organisations)-individueller und relativer Schätzung, der erste Versuch überhaupt, Komplexität zahlenmässig darzustellen. Sie sollten die Story Points daher auch nur hierfür verwenden. Die sinnvolle Frage wäre also eher „Wie lange brauchen Sie mit Ihrem Team aus 7 Zwergen durchschnittlich, um eine Aufgabe in der Größe 13 Story Points zu erledigen?“. Wer noch mehr über Story Points erfahren möchte, der kann sich hier noch etwas weiter umsehen:

Story Points
Wieso, weshalb, warum und vor allem wie?
SCRUM

Hier sieht die Sache ganz anders aus. Diese halte ich für absolut sinnvoll. Sie ist – da sie über eine vergleichende Schätzung mit einer akzeptierten Unschärfe ermittelt wird – deutlich leichter und meist unproblematischer zu ermitteln. Job size zusammen mit einem Gefühl für die Velocity eines Teams ermöglichen auch ein recht gutes Commitment und die Schätzung von job size hat noch andere Vorteile, die ich in dem oben erwähnten Artikel ausführlicher besprochen habe.

Fassen wir mal zusammen.

Der Verzicht auf Zeitschätzung ist keine Abkehr von Commitments oder der Notwendigkeit von Time-to-Market-Fähigkeit. Wir wollen die Ziele nicht aufgeben, wir haben nur gelernt, dass Zeitschätzungen uns hier nicht weiterbringen, da sie nicht so zuverlässig funktionieren, wie wir sie bräuchten.

Selbst sehr erfahrene Entwickler und Teams können hier nicht die Präzision liefern, die notwendig wäre. Sie bringen uns bei allen Bemühungen nicht weiter und wir sind gut beraten, unsere Strategie zu ändern. Stattdessen sind die Nachteile von aufwendigen Zeitschätzungen nicht zu leugnen und stellen sich dem in den Weg, was uns wesentlich voranbringt, um Business Agility in einer Organisation herzustellen, nämlich Flow.

Flow ist dabei eine sensible Angelegenheit, daher sollte man sehr bemüht sein, alles zu unterlassen was Flow beeinträchtigt. Tauschen wir also Accuracy gegen Flow ein? Ich meine nicht. Ich bin der Meinung, dass Teams mit Flow sehr lieferfähig sind und auch ein sehr gutes Forecasting hinbekommen, weil sie sich statt auf das Formalisieren von Schätzprozessen, eher auf die Inhalte konzentrieren.

Sie lernen, die Timeboxes mehr als Strukturierungselement des agilen Prozesses zu verwenden, denn als Liefermeilenstein für ein bestimmtes Set von Features. Darunter leidet zwar ein wenig das Commitment aber es ist insgesamt besser für das Time-to-Market-Ziel. Solange sich der Verlust an Commitment – letztlich repräsentiert durch das Sprint-Accuracy KPI – im Rahmen von 5% bis 15% bewegt, wäre das ein guter Deal. Geht es darüber hinaus, hat man vermutlich andere Probleme und höchstwahrscheinlich auch keinen Flow mehr. Die Schätzung von job size und das Ermitteln der Team-Velocity können hier ohnehin helfen, sich nicht völlig im Nebel zu bewegen.

Ich denke, hier wird sich spätestens zeigen, dass Flow und Sprint Accuracy auch korrelieren, jedenfalls entspricht es meiner Beobachtung, dass Teams im Flow, Commitments ganz gut abgeben und einhalten können, und umgekehrt, dass Teams mit einer sehr guten Sprint Accuracy, oft auch im Flow sind.

Die App für skalierte agile
Teams ist endlich da!
Klicke hier, um Artikel mir demselben Tags zu sehen:
Weitere interessante artikel für dich:
Behindert das neue AÜG Scrum Projekte? | scagile.work Blog
Scrum
Behindert das neue AÜG Scrum Projekte?

Was hat die Neuregelung des AÜG mit Scrum zu tun? Ich meine viel und möchte auf die neuen Herausforderungen, die sich daraus für die Planung von SCRUM Projekten in vielen Unternehmen ergeben in diesem Artikel eingehen.

Read More »

This is the H3 Tag

This is a flip box
its not any H tag
This is the heading
Lorem ipsum dolor sit amet consectetur adipiscing elit dolor
Click Here
Item One

Lorem ipsum dolor sit amet, consectetur adipisi cing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. 

Item Two

Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Item Three

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat. Lorem ipsum dolor sit amet, consectetur adipisi cing elit, sed do eiusmod.

1
Advanced Tools
Add more power to Elementor using our creative elements and make your projects look prettier than ever before.
2
All-in-One Solution
Find all the tools you’ll need to create advanced websites in one place. Stop waisting time searching for solutions.
3
Nonstop Updates
We strive to innovate when it comes to functionality. Our mission is to be the best, come and join the ride.

Article name

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit