dot.tipp - Schätzen in agilen Teams – Warum die Zeit nicht der Massstab sein sollte

Warum schätzen agile Teams eigentlich? Und was passiert, wenn sie damit aufhören? In diesem Blog beleuchten wir die unterschiedlichen Schätzpraktiken in agilen Teams, zeigen auf, warum Zeitschätzungen problematisch sind und wie eingespielte Teams ohne klassische Schätzungen auskommen können – ohne dabei die Kontrolle über ihr Backlog zu verlieren.

Die Frage hinter der Frage

In nahezu jedem agilen Team taucht sie früher oder später auf: die Frage nach dem Schätzen. Mal geht es um Planung, mal um Transparenz, mal um Kontrolle. Aber was bedeutet Schätzen eigentlich? Und welchen Zweck soll es erfüllen? In vielen Teams ist das Schätzen eine liebgewonnene Praxis, in anderen eine Quelle ständiger Diskussionen. Besonders kontrovers wird es, wenn es um das Schätzen von Zeit geht. Genau hier lohnt sich ein genauerer Blick.

Wozu wird geschätzt?

Die Gründe für Schätzungen in agilen Teams sind vielfältig. Hier eine Auswahl:

1. Um das Verständnis der Arbeit innerhalb des Teams zu erhöhen (Conversation & Collaboration)

2. Um die Planung zu präzisieren (Predictability)

3. Um die Komplexität von Aufgaben einzuschätzen

4. Um Abhängigkeiten zwischen Aufgaben zu erkennen

5. Um Aufgaben den Fähigkeiten der Teammitglieder anzupassen

6. Um die Kapazität des Teams mit dem Backlog abzugleichen

7. Um eine hohe Auslastung (Resource Efficiency) zu erreichen

8. Um Arbeit und Auslastung zu kontrollieren

9. Um über den Refinement-Prozess Arbeit ungefähr gleich gross zu halten (Ziel: No Estimations)

Diese Liste zeigt bereits, dass es sich beim Schätzen nicht nur um eine numerische Grösse handelt, sondern in erster Linie ist das Schätzen ein Instrument, damit das Team in einem gemeinsamen Ansatz ein tieferes Verständnis über die anstehenden Aufgaben entwickelt. Erst zusätzlich ist es auch ein Steuerungsinstrument mit vielen weiteren unterschiedlichsten Intentionen. Doch nicht alle dieser Intentionen sind im Sinne der agilen Werte und Prinzipien hilfreich.

Schätzen folgt keinen Selbstzweck

Schätzen ist – wenn richtig verstanden – kein Selbstzweck, sondern ein Mittel zur gemeinsamen Verständigung im Team. In der agilen Praxis wurde dies lange durch die drei C’s ausgedrückt: Card, Conversation, Collaboration.

1. Die Card steht für das Product Backlog Item – nicht als vollständige Spezifikation, sondern als Platzhalter für ein Gespräch.

2. Die Conversation beschreibt den Austausch zwischen Product Owner und Team, in dem Anforderungen geklärt, Verständnis aufgebaut und Annahmen hinterfragt werden.

3. Die Collaboration schliesslich steht für die eigentliche Umsetzung – als gemeinsame Verantwortung des Teams.

Das Schätzen hat in diesem Rahmen seinen echten Wert nicht durch die Zahl, die dabei entsteht, sondern durch den Dialog, den es auslöst. Es zwingt das Team, sich mit einem Item auseinanderzusetzen, Fragen zu stellen und Widersprüche aufzudecken – also genau jene Klarheit zu schaffen, die später einen gleichmässigen Flow ermöglicht

Warum Zeitschätzungen in agilen Teams problematisch sind

Viele Teams und selbst einige agile Coaches greifen auf die Schätzung von Zeit zurück. Dabei wirkt Zeit als scheinbar neutrale, objektive Einheit. Doch genau hier liegt das Problem:

Zeit ist manipulierbar:

Wer zu wenig Zeit hat, kann die Arbeit oberflächlich abschliessen und behaupten, sie sei erledigt. Wer zu viel Zeit hat, kann sie strecken. Zeit fördert nicht zwingend Wertschöpfung, sondern kann diese sogar behindern.

Zeit zementiert klassische Denkmuster:

Viele Organisationen sind gewohnt, in Zeit zu denken und zu messen – z. B. durch Präsenzzeit. Wenn agile Teams Zeit als Schätzgrösse übernehmen, unterstützen sie ungewollt dieses nicht-agile Denken.

Zeit verhindert Team- und Wissensentwicklung:

Wird nach Zeit geschätzt, wird die Frage gestellt, wer die Aufgabe erledigt. Das fördert Einzelverantwortung statt Teamverantwortung und verhindert Wissensaustausch.

Zeit suggeriert Genauigkeit, ist aber relativ:

Eine erfahrene Architektin braucht für eine Aufgabe zwei Stunden, ein Praktikant acht Tage. Wer mit Zeit schätzt, fördert die Zuordnung zu Experten – und verstärkt damit bestehende Abhängigkeiten.

Auch die Anzahl der erledigten Arbeiten ist kein sinnvoller Massstab

Nicht nur Zeitschätzungen führen in die Irre. Auch die Anzahl an erledigten Arbeiten – etwa User Stories oder Features pro Sprint – wird oft als Produktivitätsindikator herangezogen. Dabei entsteht ein sehr ähnlicher Effekt wie bei der Zeitschätzung: eine Zahl, die vermeintlich objektiv ist, aber keinen Aufschluss über Qualität oder Kundennutzen gibt. Teams beginnen, ihre Arbeit so zu strukturieren, dass möglichst viele Einheiten gezählt werden können. Die Folge: künstliche Zerteilung, Oberflächlichkeit und ein Fokus auf Output statt Outcome. Auch hier gilt: Entscheidend ist nicht, wie viele Stories abgeschlossen wurden, sondern welchen Unterschied sie für den Kunden gemacht haben.

Praxisbezug: Wenn Zeit zum Auswahlkriterium für Teamzugehörigkeit wird

Ein agiler Coach stellte kürzlich die Frage, warum Zeitschätzungen problematisch seien. Seine Argumentation: Zwei Teams könnten über Zeitschätzungen besser abschätzen, welche Arbeit sie übernehmen – ganz nach dem Motto: „Diese Aufgabe ist zeitlich eher was für euch.“

Doch genau hier wird ein fundamentaler Denkfehler sichtbar: In echten agilen Teams verschieben wir Arbeit nicht auf Basis der geschätzten Zeit oder Grösse. Es geht nicht darum, welche Aufgabe welchem Team „besser passt“, sondern darum, stabile und langfristig funktionierende Teams zu etablieren. Die Praxis, Aufgaben von Team zu Team zu verschieben – basierend auf Zeit, Aufwand oder Spezialwissen – führt direkt zurück in das Denken klassischer Wasserfall-Organisationen. Dort wurden Teams projektweise neu zusammengestellt – heute für ein grosses Feature, morgen für eine Migration. Dieses Denken verhindert, dass Teams zusammenwachsen, Verantwortung übernehmen und sich kontinuierlich verbessern.

Relative Schätzung als Alternative – und wie kommen wir dahin

Im Unterschied zur Zeitschätzung basiert das relative Schätzen auf dem Vergleich von Aufgaben miteinander. Eine Referenzaufgabe dient als Vergleichsgrösse. Durch Methoden wie Planning Poker oder die Fibonacci-Reihe wird eine kollektive Einschätzung erarbeitet. Diese Methode fördert die Diskussion über Inhalte, Risiken und Unbekanntes – nicht über Personen.

Langfristig eingespielte Teams entwickeln sich jedoch häufig weiter. Sie erkennen, dass ihr Backlog durch einen guten Refinement-Prozess Aufgaben enthält, die ohnehin in etwa gleich gross sind. Das Schätzen wird dadurch verzichtbar. Es entsteht ein gleichmässiger Flow an Aufgaben, die regelmässig erledigt werden können. Die Diskussion über die Grösse weicht der Überlegung, wie die Arbeit am besten gemacht werden kann.

Was heisst das für Kanban-Teams?

Im Kanban-Kontext wird Arbeit häufig nicht geschätzt. Stattdessen liegt der Fokus auf der Durchlaufzeit (Lead Time) und der kontinuierlichen Verbesserung des Workflows. Die Grösse von Aufgaben ist eher ein Indikator für Priorisierung und Risikomanagement. Ein klassisches Planning mit detaillierter Schätzung macht in Kanban-Teams wenig Sinn. Ebenso wenig macht es Sinn, Velocity oder Burndown Charts zu verwenden, da sie von einem regelmässigen Takt ausgehen, den Kanban bewusst vermeidet.

Schätzen als Mittel, nicht als Ziel

Gute agile Teams wissen, warum sie schätzen – oder eben, warum nicht mehr. Schätzen ist kein Ziel, sondern ein Mittel, um Transparenz, Lernen und gemeinsame Verantwortung zu fördern. Zeit als Schätzgrösse führt häufig in die falsche Richtung: Sie suggeriert Kontrolle, fördert Einzelverantwortung und steht dem agilen Gedanken von Lernen und Zusammenarbeit im Weg. Ähnlich irreführend ist die Anzahl abgeschlossener Aufgaben als Produktivitätsmasstab.

Wer stattdessen in Mustern denkt, Arbeit durch gute Anforderungen homogenisiert und das Team befähigt, eigenverantwortlich zu arbeiten, braucht weder Zeitschätzung noch Feature-Zählerei. Dann wird Schätzen zur Geschichte. Und das ist gut so.