Das Wichtigste in Kürze
- Der primäre Zweck agiler Schätzungen ist es, klärende Gespräche im Team zu triggern und ein gemeinsames Verständnis für die Aufgabe zu schaffen – nicht, eine präzise Zahl zu liefern.
- Menschen sind schlecht darin, absolute Zeitschätzungen abzugeben, aber relativ gut darin, Komplexität und Größe von Aufgaben im Vergleich zueinander einzuschätzen.
- Beginne mit einfachen Methoden wie der "größer/kleiner"-Frage, bevor du komplexere Frameworks wie Planning Poker einführst, um das Team nicht zu überfordern.
- Die Rolle des Product Owners ist es, das Item klar vorzustellen und Fragen zu beantworten – nicht, das Ergebnis der Schätzung zu beeinflussen.
Worum es geht
Viele Teams und Führungskräfte betrachten Schätzungen als notwendiges Übel, um Projektpläne zu füllen oder Liefertermine zu berechnen. Was ich konsistent beobachte ist, dass dieser Ansatz oft scheitert: Schätzungen sind ungenau, führen zu Frustration und das Team sieht keinen Wert in der Übung.
Das Problem ist nur: Der eigentliche Zweck geht dabei verloren. In dieser Episode klären wir die fundamentale Frage: Wozu dient agiles Schätzen überhaupt? Wir schauen uns an, warum der Fokus auf Zeit das falsche Ziel ist und wie du Schätzungen als kraftvolles Werkzeug für Team-Dialog und Klarheit einsetzen kannst.
Für wen?
Für wen?
Diese Episode ist besonders wertvoll, wenn du:
Besonders wertvoll, wenn du:
- Als Scrum Master oder Agile Coach erlebst, dass dein Team Schätzungen hasst oder sie als reine Pflichtübung abhandelt.
- Als Product Owner unsicher bist, wie du Items für eine Schätzung vorbereitest und welchen Beitrag du im Prozess leisten sollst.
- Als Teammitglied frustriert bist, weil Schätzungen sich wie ein ungenaues Ratespiel anfühlen und nie zu treffen scheinen.
- Als Führungskraft beobachtest, dass Schätzungen nicht zur besseren Planbarkeit beitragen und den Teamflow eher stören.
Episoden-Insights
Erkenntnis 1: Der wahre Wert liegt im ausgelösten Dialog
Agiles Schätzen wird oft missverstanden als reine Aufwandsschätzung für die Planung. Der größte Hebel liegt jedoch woanders: in den Gesprächen, die während des Prozesses entstehen. Wenn das Team diskutiert, warum ein Item als "groß" eingestuft wird, kommen implizite Annahmen, unterschiedliche Wissensstände und offene Fragen ans Licht. Dieser Dialog ist wertvoller als die resultierende Zahl, denn er schafft ein gemeinsames Verständnis und identifiziert vorab Risiken.
"Der größte Benefit von agilem Schätzen liegt nicht in der geschätzten Zahl, sondern in dem Gespräch, das es triggert."
Erkenntnis 2: Relative Schätzung (Größe/Komplexität) schlägt absolute Zeitschätzung
Menschen tun sich naturgemäß schwer, präzise in Zeit zu schätzen. Wir sind jedoch verhältnismäßig gut darin, Dinge relativ zueinander einzuordnen („Ist Task A komplexer als Task B?“). Ein agiler Schätzprozess sollte diese Stärke nutzen. Indem das Team über relative Größe oder Komplexität diskutiert, bleibt es im Lösungsraum und vermeidet die oft irreführende und stressbehaftete Debatte über konkrete Personentage.
Erkenntnis 3: Führe Schätzmethoden schrittweise und bedarfsgerecht ein
Versteht mich nicht falsch: Planning Poker ist ein nützliches Framework, aber es ist nicht der notwendige Startpunkt für jedes Team. Viele Teams sind damit zunächst überfordert. Ein pragmatischer Einstieg ist die einfache Frage: "Ist dieses Item größer oder kleiner als das Referenz-Item X?". Diese Methode ist niedrigschwellig, fokussiert den Dialog und bildet eine solide Basis. Erst wenn dies gut funktioniert und das Team mehr Granularität braucht, lohnt der Schritt zu formalisierteren Methoden.
Dein nächster Schritt
Kommt dir das bekannt vor? Wenn du das Potenzial von Schätzungen als Dialogwerkzeug in deinem Team heben möchtest, lass uns gemeinsam abgleichen, wo der Hebel ansetzt.
Kostenloses Strategiegespräch: Schätzungen, die Klarheit schaffen
In einem 30-minütigen Call analysieren wir, warum eure aktuellen Schätzungen nicht den gewünschten Nutzen bringen und skizzieren den nächsten, pragmatischen Schritt für dein Team.
Gespräch vereinbaren →Ressourcen
Erwähnt in der Folge
Schnelles Denken, langsames Denken von Daniel Kahneman(book)
Ralf erwähnt das Buch als Referenz dafür, dass Menschen bestimmte Dinge (wie Zeitschätzung) nicht gut können, während sie in anderen Bereichen (relatives Schätzen) besser sind. Er nutzt es, um zu erklären, warum agiles Schätzen nach Komplexität oft besser funktioniert als Zeitschätzung.
Weitere Ressourcen aus dem Netz
Externe Links zu weiterführenden Inhalten, die im Kontext dieser Episode hilfreich sein können.
Live zu diesem Thema
Vertiefe dieses Podcast-Thema in unseren Live-Webinaren und Trainings:
Die besten Tipps zu Scrum und Agilität
- Wo macht eine agile Arbeitsweise Sinn? Wo nicht?
- Was zeichnet Scrum im Kern aus?
- Wie gestalte ich Scrum effektiv aus?
- Wie arbeite ich in meiner Organisation agil?
Passende Scrum-Seiten
Weiterführende Themen & Ressourcen
20: Agiles Schätzen Nachlese - Interview mit Dennis Wagner
Agiles Schätzen wird oft falsch genutzt. Lernen Sie, wie Sie den wertvollen Team-Dialog fördern und sich von pseudogenauen Zahlen lösen. Für Scrum Master und Product Owner.
92: User Story Splitting
User Story Splitting geht nicht um kleinere Tasks, sondern um frühen Wert. Lerne, wie du durch vereinfachte Inkremente schneller lieferst und bessere Produkte baust.
86: Jira und Scrum
Jira dominiert oft Ihr Scrum-Team? Lernen Sie, wie Sie das Tool für echte Transparenz und Zusammenarbeit nutzen, statt von seinen Voreinstellungen beherrscht zu werden.