Agile Teams stoßen häufig bei Planungssitzungen auf eine gemeinsame Herausforderung: dem Kampf, vorherzusagen, wie lange eine Aufgabe dauern wird. Das Schätzen von Nutzerstories ist eine essenzielle Praxis, um Wert vorhersehbar zu liefern, wird jedoch oft zu einer Quelle von Spannungen und Angst. Wenn Teams eilig Zahlen zuweisen, ohne angemessenen Kontext, geraten sie in Fallen, die die Realität verzerrt und das Vertrauen untergraben.
Diese Anleitung untersucht die Mechanismen der effektiven Schätzung. Sie konzentriert sich darauf, von starren zeitbasierten Versprechen weg zu kommen und eine differenzierte Auffassung von Aufwand, Komplexität und Risiko zu entwickeln. Durch die Anwendung disziplinierter Techniken können Teams zuverlässige Prognosen erstellen, ohne unter dem Stress unrealistischer Fristen zu leiden. Wir werden untersuchen, warum Schätzungen scheitern, häufige Fallstricke identifizieren und praktische Methoden aufzeigen, um die Genauigkeit im Laufe der Zeit zu verbessern.
🤔 Warum Schätzen inhärent schwierig ist
Menschen sind dafür bekannt, schlecht in der Vorhersage der Zukunft zu sein. Diese kognitive Verzerrung betrifft jede Branche, doch die Softwareentwicklung verstärkt das Problem aufgrund der Komplexität der Arbeit. Wenn ein Entwickler eine Aufgabe schätzt, zählen sie nicht nur Stunden. Sie berücksichtigen:
- Technische Schulden, die bei der ersten Überprüfung nicht sichtbar sind
- Abhängigkeiten von anderen Teams oder Systemen
- Lernkurven für neue Technologien oder Frameworks
- Unerwartete Fehler, die während der Umsetzung auftreten
- Wechsel der Aufmerksamkeit und Unterbrechungen während des Sprints
Da diese Variablen ständig wechseln, ist eine konkrete Zahl wie „5 Stunden“ selten genau. Es ist besser, die Schätzung als Bereich der Wahrscheinlichkeit zu betrachten, anstatt als festes Versprechen. Diese Veränderung der Denkweise verringert den Druck und ermöglicht es dem Team, sich auf die Lieferqualität zu konzentrieren, anstatt auf eine beliebige Uhrzeit zu treffen.
🕳️ Häufige Zeitfallen, die vermieden werden sollten
Mehrere kognitive Fallen können Schätzungen beeinträchtigen. Die Erkennung dieser Muster ist der erste Schritt zur Korrektur. Unten finden Sie eine Aufschlüsselung häufiger Fehler und ihrer Auswirkungen auf die Projektgesundheit.
| Fallen | Symptom | Lösung |
|---|---|---|
| Planungsfallacy | Das Team unterschätzt die Anstrengung stets, weil sie die bestmögliche Szenario vorstellen. | Überprüfen Sie historische Daten aus früheren Sprints, um Erwartungen an die Realität zu binden. |
| Sunk-Cost-Bias | Das Team schätzt eine Geschichte weiterhin als geringen Aufwand ein, weil sie bereits Zeit in deren Diskussion investiert haben. | Ermuntern Sie frische Blickwinkel, die Geschichte zu überprüfen, bevor die Schätzung endgültig festgelegt wird. |
| Autoritäts-Bias | Senior-Mitglieder dominieren die Diskussion, und andere ergeben sich ohne eigene Beiträge ihrer Meinung. | Verwenden Sie anonyme Abstimmungstechniken, um unabhängige Meinungen von allen Mitgliedern zu sammeln. |
| Scope Creep | Die Schätzungen steigen während des Sprints, weil neue Anforderungen hinzugefügt werden, ohne den Plan anzupassen. | Sperren Sie den Umfang für den Sprint und verlangen Sie Änderungsanträge für neue Elemente. |
| Zeit mit Aufwand verwechseln | Das Team schätzt in Stunden statt in relativen Komplexitätspunkten. | Wechseln Sie zu Story Points, um Komplexität und Risiko zu berücksichtigen, nicht nur die Dauer. |
Das Verständnis dieser Fallen hilft Teams, Diskussionen effektiver zu gestalten. Wenn ein Teammitglied eine mögliche Falle aufzeigt, wandert das Gespräch von „Wie lange?“ zu „Was haben wir übersehen?“ Diese Unterscheidung ist entscheidend für die Aufrechterhaltung der Geschwindigkeit.
⏱️ Relative Schätzung im Vergleich zu absoluter Zeit
Eine der bedeutendsten Veränderungen bei reifen agilen Teams ist der Wechsel von absoluten Zeitabschätzungen zu relativen Schätzungen. Absolute Zeit (z. B. „3 Tage“) impliziert eine Sicherheit, die selten existiert. Relative Schätzung (z. B. „3 Story Points“) vergleicht die Anstrengung einer Geschichte mit einer anderen.
Die Logik hinter der relativen Schätzung
Menschen sind besser darin, Dinge miteinander zu vergleichen, als sie zu messen. Es ist einfacher zu sagen: „Diese Aufgabe ist doppelt so schwer wie jene Aufgabe“, als zu sagen: „Diese Aufgabe dauert genau 14 Stunden.“ Die relative Schätzung nutzt diese natürliche Fähigkeit aus.
- Vergleich: Das Team wählt eine Basisszene aus und bewertet neue Geschichten im Vergleich dazu.
- Skala: Eine Skala wie die Fibonacci-Folge (1, 2, 3, 5, 8, 13) wird oft verwendet. Die Abstände zwischen den Zahlen spiegeln die zunehmende Unsicherheit bei größeren Aufgaben wider.
- Fokus: Sie zwingt das Team, über die Komplexität der Arbeit statt über die Dauer zu diskutieren.
Beim Einsatz von Story Points müssen sich das Team nicht darauf einigen, wie viele Stunden ein Punkt wert ist. Dieser Wert ergibt sich im Laufe der Zeit natürlich durch die Geschwindigkeit. Diese Trennung von Komplexität und Zeit ermöglicht eine flexiblere Planung.
🤝 Techniken auf Basis von Konsens
Die Schätzung ist eine Teamaktivität, keine Einzelpersonenaktion. Wenn eine einzelne Person eine Zahl nennt, fehlt ihr oft die kollektive Weisheit der Gruppe. Konsens-Techniken stellen sicher, dass alle Perspektiven berücksichtigt werden, einschließlich derjenigen der jüngsten Entwickler und der erfahrensten Architekten.
Planning Poker
Dies ist die am weitesten verbreitete Technik zur kooperativen Schätzung. Sie verwendet Karten mit Zahlen, die Arbeitsebenen darstellen. Der Prozess funktioniert wie folgt:
- Der Product Owner präsentiert die Nutzerstory und die Akzeptanzkriterien.
- Das Team bespricht alle Fragen oder Unklarheiten bezüglich des Umfangs.
- Jedes Mitglied wählt eine Karte aus, die seine Schätzung darstellt.
- Alle zeigen ihre Karten gleichzeitig auf.
- Wenn es eine große Varianz gibt (z. B. eine 2 und eine 8), erklären die Ausreißer ihre Argumentation.
- Das Team diskutiert, bis es sich auf eine Zahl einigt oder beschließt, die Geschichte zu teilen.
Diese Methode verhindert die Anchoring-Bias, bei der die erste genannte Zahl die restliche Gruppe beeinflusst. Durch das Verbergen der Schätzungen bis zur Offenlegung stellt das Team sicher, dass unabhängig gedacht wird. Außerdem werden versteckte Risiken sichtbar. Wenn eine Person deutlich höher schätzt, könnte sie ein technisches Risiko kennen, das die anderen nicht wissen.
Schätzung bei großen Gruppen
Bei sehr großen Initiativen können Teams statt Zahlen auch T-Shirt-Größen (XS, S, M, L, XL) verwenden. Das ist nützlich bei der Release-Planung, wenn detaillierte Informationen noch nicht verfügbar sind. Sobald der Umfang klarer ist, kann das Team diese großen Aufgaben in kleinere Geschichten aufteilen und Story Points zuweisen.
⚠️ Umgang mit Unsicherheit und Risiko
Nicht alle Geschichten sind gleich. Einige sind einfache Verbesserungen, während andere umfangreiche Forschung oder die Integration mit veralteten Systemen erfordern. Die Schätzung von Unsicherheit erfordert einen anderen Ansatz als die Schätzung von bekannten Arbeiten.
Spikes
Ein Spike ist eine zeitlich begrenzte Untersuchung, die darauf abzielt, Unsicherheit zu reduzieren. Wenn ein Team eine Geschichte nicht schätzen kann, weil es den technischen Ansatz nicht versteht, sollte es stattdessen eine Spike-Geschichte erstellen. Das Ziel des Spikes ist es, ausreichend Wissen zu erzeugen, um eine korrekte Schätzung der eigentlichen Arbeit vornehmen zu können.
- Ziel definieren: Welche spezifischen Informationen müssen wir erlernen?
- Zeitlich begrenzen: Beschränken Sie den Spike auf ein paar Tage. Wenn das Problem zu komplex ist, ist ein Spike keine Lösung.
- Ausgabe: Das Ergebnis sollte eine Empfehlung, ein Proof of Concept oder eine verfeinerte Geschichte mit einer Schätzung sein.
Puffer und Kontingent
Auch bei sorgfältiger Schätzung geht etwas schief. Teams sollten Kontingent in ihre Planung einbeziehen. Das bedeutet nicht, dass jede Schätzung um 20 % aufgebläht werden soll. Stattdessen bedeutet es, anzuerkennen, dass die Geschwindigkeit schwanken wird.
Berechnen Sie die Geschwindigkeit basierend auf den letzten drei Sprints. Verwenden Sie den Durchschnitt, nicht das Maximum. Dies liefert eine realistische Grundlage dafür, wie viel Arbeit das Team übernehmen kann. Wenn eine Geschichte ein hohes Risiko birgt, kann das Team ihre Story Points erhöhen, um die Wahrscheinlichkeit einer Verzögerung widerzuspiegeln.
📈 Geschwindigkeit und Metriken
Die Geschwindigkeit ist die Maßgröße dafür, wie viel Arbeit ein Team in einem Sprint erledigt. Sie wird berechnet, indem die Story Points aller akzeptierten User Stories addiert werden. Obwohl die Geschwindigkeit eine nützliche Metrik ist, wird sie oft missbraucht.
Geschwindigkeit als Kompass
Die Geschwindigkeit sollte die zukünftige Planung leiten, nicht als Leistungsziel dienen. Der Vergleich der Geschwindigkeit zwischen Teams ist sinnlos, weil jedes Team „einen Story Point“ unterschiedlich definiert. Ein Punkt für Team A könnte 2 Stunden entsprechen, während ein Punkt für Team B 4 Stunden entsprechen könnte.
Verwenden Sie die Geschwindigkeit, um:
- Vorherzusagen, wann eine Liste von Features abgeschlossen sein wird.
- Trends in der Teamkapazität im Laufe der Zeit zu erkennen.
- Zu erkennen, wann das Team zu viel verspricht oder die Kapazität nicht ausnutzt.
Verfolgung der Schätzungsgenauigkeit
Teams können verfolgen, wie nahe ihre Schätzungen an der tatsächlichen benötigten Zeit lagen. Diese Daten sind jedoch sensibel. Wenn sie strafend eingesetzt werden, werden sie ehrliche Schätzungen unterdrücken. Wenn sie konstruktiv genutzt werden, helfen sie, zukünftige Schätzungen zu verfeinern.
Überprüfen Sie die Daten in den Retrospektiven. Fragen Sie:
- Haben wir eine Abhängigkeit übersehen?
- War das Akzeptanzkriterium unklar?
- Sind wir auf unerwartete technische Schulden gestoßen?
Konzentrieren Sie sich auf die Verbesserung des Prozesses und nicht auf die individuelle Leistung des Schätzers.
🔧 Prozessverfeinerung
Die Schätzung ist kein einmaliger Vorgang. Es handelt sich um eine kontinuierliche Verbesserungsschleife. Je mehr das Team über das Produkt und die Technologie lernt, desto genauer werden ihre Schätzungen.
Verfeinerung von Backlog-Elementen
Teams sollten keine Geschichten schätzen, die unklar oder unvollständig sind. Dies führt zum „Müll rein, Müll raus“-Problem. Product Owner und Business Analysten müssen sicherstellen, dass Geschichten klar sind, bevor sie in die Schätzphase eintreten. Die INVEST-Kriterien (Unabhängig, Verhandelbar, Wertvoll, Schätzbar, Klein, Prüfbar) bieten eine Checkliste für die Bereitschaft.
Aufteilung großer Geschichten
Wenn ein Team eine Geschichte konsequent als 8 oder 13 schätzt, ist sie wahrscheinlich zu groß. Große Geschichten sind schwer zu schätzen, weil sie versteckte Unteraufgaben enthalten. Teilen Sie sie in kleinere, vertikale Funktionsblöcke auf. Kleinere Geschichten reduzieren das Risiko und verbessern die Vertrauenswürdigkeit der Schätzung.
Regelmäßige Kalibrierung
Teams sollten regelmäßig Kalibrierungssitzungen abhalten. Überprüfen Sie einige abgeschlossene Stories und besprechen Sie, wie sich die tatsächliche Aufwandsschätzung zur ursprünglichen Schätzung verhält. Dadurch bleibt das Team in Bezug auf die Bedeutung eines „Punkts“ synchronisiert. Im Laufe der Zeit kann sich die Bedeutung eines Punkts ändern, wenn das Team wächst oder sich die Technologie-Stack verändert.
🧠 Das menschliche Element
Die Schätzung ist tiefgreifend psychologisch geprägt. Die Angst vor Verpflichtung treibt einige dazu, zu unterschätzen, während die Angst vor Versagen andere dazu treibt, zu überschätzen. Die Schaffung einer sicheren Umgebung für die Schätzung ist entscheidend.
- Psychologische Sicherheit:Teammitglieder müssen sich sicher fühlen, zuzugeben, dass sie die Antwort nicht kennen. Ehrlichkeit wird gegenüber Selbstsicherheit bevorzugt.
- Trennen Sie Schätzung von Verpflichtung:Die Schätzung einer Story bedeutet nicht, dass das Team versprochen hat, sie bis Freitag abzuschließen. Es handelt sich um eine Prognose, keine Verpflichtung.
- Respektieren Sie die Schätzung:Sobald eine Schätzung vereinbart ist, dürfen Sie sie nicht willkürlich ändern, um einem Termin anzupassen. Die Änderung der Schätzung, um einem Datum zu entsprechen, macht den Planungsprozess ungültig.
Wenn das Team sich sicher fühlt, liefert es bessere Daten. Bessere Daten führen zu besserer Planung. Bessere Planung führt zu weniger Stress. Dieser Zyklus fördert eine Kultur des Vertrauens und der Zuverlässigkeit.
📝 Zusammenfassung der Best Practices
Zusammenfassend erfordert eine effektive Schätzung Disziplin, Transparenz und einen Fokus auf den relativen Aufwand. Vermeiden Sie die Versuchung, Genauigkeit zu erzwingen, wo keine existiert. Stattdessen nehmen Sie die Unsicherheit an und verwalten Sie sie durch Kommunikation und Pufferplanung.
- Verwenden Sie relative Schätzungen (Story Points) anstelle von absoluter Zeit.
- Ziehen Sie das gesamte Team in den Schätzungsprozess ein.
- Identifizieren und mindern Sie Risiken mithilfe von Spikes.
- Behandeln Sie die Geschwindigkeit als Planungsinstrument, nicht als KPI.
- Verfeinern Sie kontinuierlich das Backlog, um sicherzustellen, dass die Stories für die Schätzung bereit sind.
- Pflegen Sie eine Kultur der psychologischen Sicherheit, um ehrliche Beiträge zu fördern.
Durch die Einhaltung dieser Prinzipien können Teams die Komplexität der Softwareentwicklung mit größerer Sicherheit meistern. Die Schätzung wird zu einem Werkzeug für Planung und Kommunikation statt zu einer Quelle von Angst. Das Ziel ist nicht Perfektion, sondern eine konsistente Genauigkeit, die es ermöglicht, Wert vorhersagbar zu liefern.
Denken Sie daran, dass die besten Schätzungen jene sind, die sich entwickeln, während das Team lernt. Bleiben Sie flexibel, halten Sie die Kommunikation offen und konzentrieren Sie sich auf den gelieferten Wert. Dieser Ansatz sichert langfristigen Erfolg, ohne das Team dabei auszubrennen.
