7 Agile Schätztechniken für 2025

TL;DR: Wähle Schätztechniken, die zu deinem Kontext passen. Verwende Planning Poker und Story‑Punkte für die Sprint‑Ebene und Affinity, T‑Shirt‑Größen oder das Bucket‑System, um große Backlogs schnell zu priorisieren. Nutze Ideal Days und Drei‑Punkt‑Schätzung, wenn Kalenderzeit oder Unsicherheit relevant sind. Kombiniere Methoden, messe Ergebnisse und iteriere, um Prognosen zu verbessern.

Warum agile Schätzung wichtig ist

„Wie lange wird das dauern?“ ist die universelle Projektfrage. Bessere Schätzungen verbessern Planung, Budgetierung und das Vertrauen der Stakeholder¹. Agile Schätzung geht nicht um perfekte Vorhersagen; es geht darum, gemeinsames Verständnis des Umfangs zu schaffen, Risiken sichtbar zu machen und Daten zu erzeugen, die dich bessere Entscheidungen treffen lassen.

Diese Techniken funktionieren teamübergreifend. Software‑Teams nutzen sie für die Sprintplanung. Fertigungs‑ und Bau‑Teams wandeln relative Aufwände in Kosten‑ und Kapazitätsprognosen um. Marketing‑Teams nutzen sie zur Umfangsbestimmung von Kampagnen. Nutze Schätzung, um Entscheidungen zu informieren, nicht um unrealistische Deadlines durchzusetzen².

„Pro‑Tipp: Behandle Schätzung als Gespräch, nicht als einmalige Kalkulation.“

Kurze Inhaltsübersicht

1. Planning Poker (Scrum Poker)
2. Story‑Punkte
3. T‑Shirt‑Größen
4. Affinitäts‑Schätzung
5. Ideale Tage
6. Das Bucket‑System
7. Drei‑Punkt‑Schätzung

Vergleichs‑ und Implementierungstipps folgen jeder Technik.

Einleitung

Schätzung trennt Wunschdenken von vorhersagbarer Auslieferung. Dieser Leitfaden führt durch sieben praktische agile Schätztechniken für 2025, von Planning Poker bis zur Drei‑Punkt‑Schätzung. Zu jeder Technik erfährst du, wann du sie einsetzen solltest, Vor‑ und Nachteile, schnelle Implementierungstipps und Links zu Tools, damit du die Methode sofort anwenden kannst.

Lies ihn durch, um ein oder zwei Techniken auszuwählen, die du in diesem Sprint pilotieren willst, und nutze die Checkliste am Ende, um schnelle Erfolge festzuhalten.

1. Planning Poker (Scrum Poker)

Was es ist: Eine konsensbasierte, spielerische Methode, bei der Teammitglieder privat eine Zahl wählen — oft aus einer Fibonacci‑ähnlichen Sequenz — um die relative Größe einer Story zu schätzen.

Wie es funktioniert: Der Product Owner erklärt die Story. Jede Teilnehmerin wählt privat eine Karte und deckt zeitgleich auf. Unterschiede führen zu kurzen Diskussionen, meist moderiert durch die höchsten und niedrigsten Schätzer.

Wann zu verwenden: Sprintplanung und detaillierte Story‑Schätzung, wenn du kollaborative, ent‑biaste Schätzungen möchtest.

Vorteile: Fördert Beteiligung, deckt versteckte Annahmen auf und reduziert Anker‑Bias.

Nachteile: Kann bei vielen kleinen Items langsam sein und benötigt eine Moderation.

Umsetzbare Tipps:

• Lege ein oder zwei Referenz‑Stories als Baselines fest.
• Timeboxe Debatten auf 2–3 Minuten, um Analyseparalyse zu vermeiden.
• Beziehe funktionsübergreifende Rollen ein: Entwickler, QA, Designer und Product Owner.

Interne Links: Nutze Planning‑Poker‑Ergebnisse zur Information deiner Sprintplanung und Backlog Seiten.

2. Story‑Punkte

Was es ist: Eine abstrakte Einheit, die Komplexität, Aufwand und Unsicherheit erfasst. Story‑Punkte vergleichen Items relativ zueinander, üblicherweise mit einer modifizierten Fibonacci‑Sequenz.

Wie es funktioniert: Kalibriere mit Referenz‑Stories, vergebe Punkte basierend auf relativer Größe und verfolge abgeschlossene Punkte pro Sprint, um die Velocity zu bestimmen.

Wann zu verwenden: Laufende Sprintplanung und velocity‑basierte Forecasts.

Vorteile: Fördert relative Größenbestimmung, unterstützt Velocity‑Tracking und vermeidet die falsche Präzision von Stunden.

Nachteile: Erfordert Kalibrierung; Teams neigen manchmal dazu, Punkte in Stunden umzuwandeln — vermeide das.

Umsetzbare Tipps:

• Bewahre Referenz‑Stories und überprüfe sie regelmäßig.
• Stelle relative Fragen: „Ist das größer oder kleiner als unsere Referenz?“
• Warte 3–5 Sprints, bis sich die Velocity stabilisiert hat, bevor du feste Prognosen machst.

Interne Links: Verknüpfe Story‑Punkte‑Ergebnisse mit Release‑Planung und deinem Analytics‑Dashboard, falls du dort Velocity trackst.

3. T‑Shirt‑Größen

Was es ist: Kategoriale Hoch‑Level‑Größenbestimmung mit XS, S, M, L, XL, um Arbeit schnell zu klassifizieren.

Wie es funktioniert: Weise während früher Planungsschritte oder Grooming‑Sessions eine T‑Shirt‑Größe zu. Optional kannst du Größen später für Velocity‑Tracking in Story‑Punkte‑Bereiche abbilden.

Wann zu verwenden: Frühe Projektphasen, Portfolio‑Planung und Priorisierungs‑Workshops.

Vorteile: Schnell, intuitiv und reduziert Analyseparalyse.

Nachteile: Weniger präzise; üblicherweise musst du Größen für die Sprintplanung in granularere Einheiten überführen.

Umsetzbare Tipps:

• Definiere Größenkriterien in klarer Sprache, z. B. „S = weniger als ein idealer Tag fokussierter Arbeit“.
• Bewahre Referenz‑Items für jede Größe.
• Mappe Größen auf Story‑Punkte, wenn du sie in Sprint‑Forecasts einfließen lassen willst.

Interne Links: Gut geeignet zur Verknüpfung mit der Produkt‑Roadmap und Portfolio‑Planungsdokumenten.

4. Affinitäts‑Schätzung

Was es ist: Schnelles Gruppieren vieler Backlog‑Items nach relativer Größe mittels stillem Sortieren und kollaborativer Verfeinerung.

Wie es funktioniert: Lege Stories auf Haftnotizen, physisch oder digital. Das Team gruppiert ähnlich große Items still, diskutiert danach Ausreißer und versieht Gruppen mit Größen oder Story‑Punkten.

Wann zu verwenden: Große Backlog‑Verfeinerung, erste Projekt‑Kickoffs und abteilungsübergreifende Abstimmung.

Vorteile: Sehr schnell, verhindert Ankerbildung und skaliert gut bei vielen Items.

Nachteile: Benötigt Nacharbeit für prioritäre Items und Gruppierungen können subjektiv sein.

Umsetzbare Tipps:

• Beginne still, um frühes Ankern zu vermeiden.
• Begrenze Kategorien auf 5–7, um Fokus zu halten.
• Nutze digitale Whiteboards für verteilte Teams und tagge Items zur Nachverfolgung.

Interne Links: Verknüpfe Affinity‑Session‑Ergebnisse mit deinem Backlog und Priorisierungs Board.

5. Ideale Tage

Was es ist: Zeitbasierte Schätzung ausgedrückt als ungestörte, fokussierte Arbeitstage.

Wie es funktioniert: Schätze, wie viele „ideale“ Tage eine Aufgabe ohne Meetings oder Ablenkungen dauern würde, und wende dann einen Umrechnungsfaktor an, um Kalenderzeit anzunähern.

Wann zu verwenden: Teams, die von zeitbasierter Planung kommen, compliance‑intensive Projekte und Kapazitätsplanung, bei denen Kalendertage relevant sind.

Vorteile: Intuitiv und leicht für Stakeholder verständlich.

Nachteile: Kann als hartes Deadline‑Versprechen missbraucht werden; du brauchst historische Daten, um ideale Tage zuverlässig in Kalendertage zu konvertieren.

Umsetzbare Tipps:

• Wähle einen realistischen Umrechnungsfaktor (z. B. 1 idealer Tag = 1,5–2 Kalendertage) und validiere ihn mit historischen Daten³.
• Halte Schätzungen auf die Kernarbeit fokussiert; füge separate Schätzungen für Testing, Deployment und Reviews hinzu.
• Behandle ideale Tage nicht als garantierte Deadlines.

Interne Links: Nutze Ideale‑Tage‑Ergebnisse für die Kapazitätsplanung.

6. Das Bucket‑System

Was es ist: Schnelles Sortieren von User Stories in vordefinierte Buckets auf einer exponentiellen Skala für Massen‑Schätzung.

Wie es funktioniert: Erstelle Buckets (0, 1, 2, 4, 8, 16, 32, 64, 100+), lies Stories laut vor und platziere sie zügig in Buckets. Priorisiere Geschwindigkeit über perfekte Präzision.

Wann zu verwenden: Workshops zur Schätzung von Hunderten von Items, erste Release‑Planung und abteilungsübergreifende Sessions.

Vorteile: Extrem schnell, reduziert Ermüdung und skaliert gut.

Nachteile: Benötigt Nachverfeinerung für große, hochprioritäre Items.

Umsetzbare Tipps:

• Kalibriere Buckets mit Referenz‑Stories.
• Timeboxe die Session und setze eine Moderation ein.
• Schätze Top‑Items später erneut mit Planning Poker oder Story‑Punkten.

Interne Links: Verbinde Bucket‑Ergebnisse mit Priorisierung und Budgetierungsseiten. Für marketingbezogene Kostenprojektionen, ziehe den Email List Value Estimator in Betracht.

7. Drei‑Punkt‑Schätzung

Was es ist: Eine risikobewusste Methode, die Optimistische (O), Wahrscheinlichste (M) und Pessimistische (P) Schätzungen erfasst und dann einen gewichteten Durchschnitt berechnet, üblicherweise (O + 4M + P) / 6.

Wie es funktioniert: Sammle O, M und P für eine Story und berechne den erwarteten Wert. Nutze dies für probabilistische Forecasts und risikobewusste Planung.

Wann zu verwenden: Hochrisikante, komplexe oder regulierte Arbeiten, bei denen Unsicherheit Zeitplan oder Kosten wesentlich beeinflusst.

Vorteile: Berücksichtigt explizit Unsicherheit und fördert bessere Risikodiskussionen.

Nachteile: Erfordert mehr Aufwand für Sammlung und Berechnung; nicht ideal für jedes kleine Task.

Umsetzbare Tipps:

• Beginne mit Wahrscheinlichste (M), um Diskussionen zu verankern, und hinterfrage dann optimistische und pessimistische Szenarien.
• Definiere glaubwürdige pessimistische Szenarien, z. B. Lieferanten‑Verzögerungen oder blockierte APIs.
• Wende selektiv auf hochrelevante Items an und speise Ergebnisse in Finanzmodelle oder Zeitrechner ein.

Interne Links: Nutze Drei‑Punkt‑Ergebnisse mit dem Manufacturing Production Time Estimator und verknüpfe Erkenntnisse mit der Finanzplanung.

Vergleich auf einen Blick

Wie man die richtige Technik auswählt

• Verwende schnelle, hoch‑level Methoden (Affinity, T‑Shirt, Bucket), um große Backlogs zu triagieren und zu priorisieren.
• Nutze kollaborative Konsens‑Methoden (Planning Poker, Story‑Punkte) für Sprint‑Level‑Verpflichtungen.
• Verwende zeit‑ oder risikobewusste Methoden (Ideale Tage, Drei‑Punkt), wenn Stakeholder Kalender‑Schätzungen benötigen oder wenn Unsicherheit hoch ist.

Führe kleine Experimente durch: Probiere eine Technik für einen Sprint oder ein Projekt, messe Genauigkeit und Team‑Feedback und iteriere.

Implementierungs‑Checkliste (schnelle Erfolge)

• Wähle ein oder zwei Primärtechniken und dokumentiere deine Regeln.
• Erstelle und pflege Referenz‑Stories.
• Verfolge Ergebnisse (Velocity, Ist‑Werte vs. Schätzungen) für 3–6 Sprints.
• Nutze Retrospektiven, um deine Schätzregeln zu verfeinern.
• Integriere Ergebnisse in Planungstools und Finanzmodelle.

Interne Verlinkung

• Produkt‑Roadmap und Release‑Planung: product roadmap, release planning
• Backlog‑ und Sprint‑Seiten: backlog, sprint planning
• Kapazität, Finanzen und Tools: capacity planning, financial planning, tools
• Fallstudien und andere Blogbeiträge: case studies, blog: agile estimation

Abschließende Gedanken

Schätzung ist ein Handwerk, das du durch Übung, Messen und Anpassung schärfst. Keine einzelne Technik passt in jeden Kontext. Mische Methoden, halte Gespräche fokussiert und nutze Daten, um deinen Ansatz zu verfeinern. Der eigentliche Wert entsteht durch das gemeinsame Verständnis, das du aufbaust, nicht nur durch die Zahlen.

Für Teams, die bereit sind, diese Techniken anzuwenden: Probiere den Manufacturing Production Time Estimator, um relative Schätzungen in Zeitprojektionen zu überführen und Szenarien zu testen.

Bereit, vom Raten zur vorhersagbaren Auslieferung überzugehen? Probiere diese Sprint eine neue Technik und messe die Auswirkungen.

Autor und Veröffentlichungsdatum wurden aus dem Originalartikel übernommen.

Häufig gestellte Fragen

F: Welche Technik sollten wir zuerst ausprobieren?

A: Beginne mit einer schnellen, wenig aufwändigen Methode – T‑Shirt‑Größen oder Affinitäts‑Schätzung – um das Backlog zu triagieren, und nutze dann Planning Poker oder Story‑Punkte für Sprint‑Level‑Arbeit.

F: Wie messen wir, ob unsere Schätzungen besser werden?

A: Verfolge Ist‑Werte vs. Schätzungen, beobachte die Velocity über 3–6 Sprints und nutze Retrospektiven, um herauszufinden, warum Schätzungen verfehlt oder getroffen wurden.

F: Wann sollten wir Drei‑Punkt oder Ideale Tage verwenden?

A: Nutze Drei‑Punkt für Arbeiten mit hoher Unsicherheit und hohem Einfluss, bei denen Risiko relevant ist. Verwende Ideale Tage, wenn Stakeholder kalenderbezogene Kapazitätsplanung benötigen.

Kurze Q&A‑Zusammenfassung

F: Wie wähle ich eine Methode für ein großes Backlog? A: Verwende Affinität oder das Bucket‑System, um schnell zu triagieren, und schätze dann Top‑Items mit Planning Poker neu.

F: Wie mache ich Schätzungen für Stakeholder nützlich? A: Mapp relative Schätzungen auf Kapazität oder Kalenderzeit (nutze Ideale Tage mit einem validierten Umrechnungsfaktor) und teile Velocity‑Trends.

F: Wie gehen wir mit Unsicherheit um? A: Wende Drei‑Punkt‑Schätzung auf wirkungsstarke Items an und baue Puffer in Forecasts ein.

Zusätzliche knappe Q&A (unten im Artikel)

F: Wie viele Techniken sollte ein Team übernehmen? A: Beginne mit einer Triage‑Methode und einer Sprint‑Level‑Methode. Ergänze bei Bedarf weitere.

F: Was ist der einfachste Weg, Schätz‑Bias zu reduzieren? A: Nutze stille Schätzung (Affinity oder Planning Poker) und Referenz‑Stories, um Diskussionen zu verankern.

F: Wie schnell sollten wir eine neue Methode testen? A: Führe ein fokussiertes Experiment für 1–2 Sprints durch, sammle Daten und prüfe das Ergebnis in einer Retrospektive.