Agile Estimation Techniques im Vergleich
Planning Poker, T-Shirt Sizing, Bucket System: welche Schätzmethode passt zu welchem Team? Und warum eine einzelne Zahl selten reicht, um Komplexität, Aufwand und Risiko zu beschreiben.
Warum überhaupt schätzen?
Schätzungen sind kein Vertrag, sondern ein Kommunikationsmittel. Der eigentliche Wert entsteht in der Diskussion: Unterschiedliche Bewertungen decken unterschiedliches Verständnis auf. Eine gute Estimation Technique optimiert deshalb nicht auf Präzision, sondern auf gemeinsames Verständnis in kurzer Zeit.
Die gängigen Methoden
Planning Poker
Stärke: Klassiker für Scrum-Teams: alle bewerten gleichzeitig, Ausreißer werden diskutiert.
Grenze: Wird bei vielen Stories langsam und presst Komplexität, Aufwand und Risiko in eine Zahl.
T-Shirt Sizing
Stärke: Schnelle, grobe Einordnung (XS-XL): ideal für frühes Backlog-Grooming und Roadmaps.
Grenze: Zu unpräzise für Sprint Planning; Größen bedeuten für jedes Teammitglied etwas anderes.
Bucket System
Stärke: Sehr effizient für große Backlogs: Stories werden parallel in Wert-Buckets einsortiert.
Grenze: Weniger Diskussion, dadurch weniger gemeinsames Verständnis der Story.
Affinity Estimation
Stärke: Relatives Sortieren an der Wand: gut, um Dutzende Items in kurzer Zeit zu ordnen.
Grenze: Braucht einen Workshop-Rahmen und funktioniert remote nur mit gutem Tooling.
Dot Voting
Stärke: Leichtgewichtig für Priorisierung und erste Einschätzungen.
Grenze: Sichtbare Stimmen erzeugen Anchoring: die lauteste Meinung gewinnt.
Three-Point / PERT
Stärke: Best-, Likely- und Worst-Case machen Unsicherheit explizit sichtbar.
Grenze: Rechenaufwand und Scheingenauigkeit, wenn die Datenbasis fehlt.
Story Points vs. Stunden
Story Points sind relativ: Sie vergleichen Stories miteinander, statt eine absolute Dauer zu versprechen. Das macht sie robust gegen unterschiedliche Erfahrungsstände im Team und gegen Druck von außen. Stunden hingegen wirken konkret, verleiten aber zu Scheingenauigkeit und werden schnell als Zusage gelesen.
- Story Points: gut für Forecasting über Velocity, unabhängig von der Person, die umsetzt.
- Stunden: sinnvoll für kurzfristige Kapazitätsplanung und Tasks innerhalb eines Sprints.
- Nie beides parallel als Pflicht, sonst rechnet das Team Points wieder in Stunden zurück.
Das Problem der einen Zahl
Fast alle klassischen Techniken enden in einem einzigen Wert. Damit verschwindet die Information, warum eine Story groß ist: Ist sie fachlich knifflig? Einfach nur viel Arbeit? Oder hängt sie an einem unsicheren Drittsystem? Genau diese Unterscheidung braucht ein Product Owner, um zu priorisieren.
Mehrdimensional schätzen mit Consonus
Consonus trennt die Schätzung in drei Dimensionen. Jedes Teammitglied bewertet anonym, das verhindert Anchoring durch die lauteste Stimme.
Komplexität
Wie anspruchsvoll ist die Lösung fachlich und technisch?
Aufwand / Zeit
Wie viel Arbeit steckt realistisch drin?
Risiko
Wie viel Unsicherheit, Abhängigkeit und Unbekanntes gibt es?
Die drei Dimensionen bleiben nicht als separates Reporting-Format im Raum stehen, sondern werden automatisch in die Zahl übersetzt, die das Team sowieso braucht: zum Beispiel Story Points oder T-Shirt Sizes. Das passiert erst nach der Schätzung, nicht davor.
Der große Vorteil liegt in der Diskussion. Statt sich über eine fiktive Zahl wie "Story Points" oder "das ist eine 8" zu streiten, spricht das Team über die konkreten Dimensionen. Alle Entwickler diskutieren dieselbe Frage und haben dadurch dasselbe Verständnis davon, worüber geredet wird.
Welche Methode passt zu deinem Team?
Für frühes Roadmap-Grooming reicht T-Shirt Sizing. Für große Backlogs ist das Bucket System am schnellsten. Für Refinement und Sprint Planning, wo Entscheidungen wirklich getroffen werden, lohnt sich eine mehrdimensionale, anonyme Bewertung: sie kostet kaum mehr Zeit und liefert deutlich mehr Kontext.
Bereit für klarere Schätzungen?
Starte in unter 60 Sekunden. Keine Kreditkarte, keine Accounts für Teilnehmende.