User Story Schätzung: 5 Methoden im Vergleich

“Wie lange dauert das?” — eine Frage, die jedes Entwicklungsteam kennt. Und eine, bei der viele Teams ins Schwitzen kommen. Die ehrliche Antwort wäre oft: “Kommt drauf an.” Aber das hilft dem Stakeholder nicht weiter, der einen Release-Termin braucht.

Die Antwort mit Story Points statt Stunden zu geben, fühlt sich anfangs seltsam an. “13 Punkte” klingt weniger greifbar als “drei Tage”. Aber genau das ist der Punkt: User Story Estimation mit relativer Komplexität ist einer der Gründe, warum agile Teams besser planen als klassische Projekte. Nicht weil die Schätzungen genauer wären — sondern weil sie ehrlicher mit Unsicherheit umgehen.

In diesem Guide vergleiche ich fünf bewährte Schätzmethoden. Du erfährst, wann welche passt, wie du typische Fehler vermeidest und warum das Gespräch über Komplexität oft wertvoller ist als die Zahl am Ende.

Warum schätzen wir User Stories?

Die offensichtliche Antwort: um zu wissen, was in den nächsten Sprint passt. Aber Schätzungen leisten mehr als das.

Sprint-Planung ist der direkteste Nutzen. Ohne Schätzung wird das Sprint Planning zum Ratespiel. Das Team nimmt sich zu viel vor, liefert nicht alles, und der Frust wächst — bei Entwicklern wie bei Stakeholdern. Mit Schätzungen entsteht über mehrere Sprints ein Gefühl dafür, wie viel Arbeit das Team realistisch schafft.

Release-Prognosen sind der zweite Grund. “Wann ist das Feature fertig?” — diese Frage werden Stakeholder immer stellen. Story Points liefern keine Datumsgarantie, aber sie ermöglichen ehrliche Aussagen wie: “Das Backlog hat 130 Punkte, wir schaffen etwa 26 pro Sprint, also rechnet mit fünf Sprints.” Das ist keine Zusage, aber eine fundierte Orientierung.

Komplexitäts-Erkennung ist der oft unterschätzte dritte Nutzen. Wenn eine Story auf 13 oder 21 Punkte geschätzt wird, ist das ein Signal: Hier stimmt etwas nicht. Die Story ist zu groß, zu unklar oder zu technisch riskant. Das Schätzgespräch deckt diese Probleme auf — bevor sie im Sprint explodieren.

Story Points vs. Zeitschätzung

Warum keine Stunden?

Menschen unterschätzen systematisch. Eine 4-Stunden-Aufgabe wird zur Tagesaufgabe, weil Meetings, Code Reviews und Bugs dazukommen. Story Points umgehen das Problem: Sie messen Komplexität, nicht Kalenderzeit.

Die 5 Schätzmethoden im Vergleich

1. Planning Poker

Die bekannteste Methode — und aus gutem Grund. Planning Poker kombiniert individuelle Einschätzung mit Teamdiskussion und vermeidet dabei typische Gruppendynamik-Fallen.

So funktioniert’s:

1. Der Product Owner erklärt die Story
2. Das Team diskutiert und stellt Fragen
3. Jeder wählt verdeckt eine Karte (1, 2, 3, 5, 8, 13, 21…)
4. Alle decken gleichzeitig auf
5. Bei großen Abweichungen: Diskussion, dann erneut schätzen

Warum die verdeckte Wahl so wichtig ist

Stell dir vor, der Senior-Entwickler sagt als Erster: “Das ist eine 3.” Was passiert? Die anderen denken: “Er kennt sich aus, wird schon stimmen.” Auch wenn jemand eigentlich an eine 8 gedacht hätte, passt er sich an.

Die verdeckte Wahl verhindert genau das. Wenn alle gleichzeitig aufdecken und einer zeigt 3, ein anderer 8 — dann gibt es etwas zu besprechen. Vielleicht hat der eine eine technische Hürde gesehen, die der andere übersehen hat. Oder umgekehrt: Einer kennt eine Abkürzung. Beides ist wertvolle Information, die sonst verloren ginge.

Die Diskussion ist der eigentliche Wert

Erfahrene Teams wissen: Die Zahl am Ende ist fast nebensächlich. Der Wert liegt im Gespräch. Wenn ein Backend-Entwickler eine 5 zeigt und der Frontend-Entwickler eine 13, dann verstehen beide die Story offenbar unterschiedlich. Diese Diskrepanz früh zu entdecken ist Gold wert — sie würde sonst im Sprint als Überraschung auftauchen.

Die Einschränkungen

Planning Poker braucht Zeit — rechne mit 5-10 Minuten pro Story. Das summiert sich. Für ein Backlog mit 30 Stories wird das Refinement zum Halbtagsjob. Außerdem funktioniert die Methode am besten, wenn das Team sich kennt und offen diskutieren kann. Frisch zusammengewürfelte Teams tun sich oft schwer, weil die psychologische Sicherheit noch fehlt.

Remote-Teams können Planning Poker mit digitalen Tools wie Miro, Planning Poker Online oder direkt in Jira umsetzen — das funktioniert erstaunlich gut, wenn alle ihre Kamera anhaben.

Ideal für: Etablierte Teams mit 4-8 Personen, die regelmäßig Refinement machen und den Zeitaufwand akzeptieren.

2. T-Shirt Sizes

Wenn Planning Poker zu aufwändig ist oder das Team noch keine Erfahrung mit Story Points hat, bieten T-Shirt-Größen einen niedrigschwelligen Einstieg.

So funktioniert’s:

Stories werden in Größen eingeteilt: XS, S, M, L, XL. Keine exakten Zahlen, nur grobe Kategorien. Das Team einigt sich schnell: “Das ist eindeutig ein L” oder “Das fühlt sich nach S an.”

Hilfreich sind Referenz-Stories: “Die Login-Implementierung war ein M — ist diese Story größer oder kleiner?” Durch den Vergleich wird die Einschätzung greifbarer, ohne dass man über konkrete Zahlen diskutieren muss.

Warum das funktioniert

T-Shirt-Größen senken die Hemmschwelle. Niemand muss sich auf eine konkrete Zahl festlegen und später rechtfertigen. “M” ist ungenauer als “5 Punkte”, aber das ist in frühen Projektphasen oft genau richtig — wenn sich ohnehin noch viel ändern wird, braucht man keine Scheingenauigkeit.

Außerdem versteht jeder intuitiv, was “S” und “XL” bedeuten. Es braucht keine Erklärung der Fibonacci-Reihe, keine Diskussion über relative Komplexität. Das Team kann sofort loslegen.

Die Grenzen

Für präzise Sprint-Planung reicht die Methode nicht. “L” sagt nicht, wie viel größer als “M” — ist es doppelt so viel Aufwand? Dreimal? Deshalb funktioniert Velocity-Berechnung mit T-Shirt-Größen schlecht. Viele Teams starten mit T-Shirts und wechseln später zu Story Points, wenn sie einen stabileren Planungshorizont brauchen.

Ideal für: Neue Teams, frühe Projektphasen, grobe Backlog-Priorisierung — überall dort, wo Geschwindigkeit wichtiger ist als Präzision.

3. Affinity Mapping (Wall Estimation)

Wenn ihr ein großes Backlog mit 30, 50 oder mehr Stories vor euch habt, ist Planning Poker keine Option — das würde Tage dauern. Affinity Mapping löst dieses Problem: Das gesamte Backlog wird in einer Session grob geschätzt, oft in unter zwei Stunden.

So funktioniert’s:

Die Methode ist physisch und kollaborativ. An einer Wand oder einem großen Whiteboard hängt ihr eine Skala: 1 - 2 - 3 - 5 - 8 - 13. Dann bekommt jedes Teammitglied einen Stapel Story-Karten.

Die Regeln sind einfach: Jeder nimmt eine Karte, liest sie kurz und hängt sie unter die Zahl, die ihm passend erscheint. Ohne lange Diskussion, ohne Abstimmung. Wer eine Karte sieht, die falsch hängt, darf sie still verschieben. Erst wenn mehrere Leute eine Karte hin- und herschieben, wird kurz diskutiert.

Warum das funktioniert

Der Vergleich zwischen Stories passiert ganz natürlich. Wenn du eine neue Karte aufhängst, siehst du sofort: “Die Stories bei der 5 sind ungefähr so komplex — passt meine dazu?” Das relative Schätzen wird intuitiv, weil alles gleichzeitig sichtbar ist.

Außerdem arbeitet das ganze Team parallel statt nacheinander. Bei Planning Poker schätzt einer, dann diskutieren alle. Bei Affinity Mapping sortieren alle gleichzeitig — das spart enorm Zeit.

Die Grenzen

Der Preis für Geschwindigkeit ist Tiefe. Bei Planning Poker entsteht oft ein wertvolles Gespräch über technische Details oder versteckte Komplexität. Bei Affinity Mapping bleibt dafür wenig Raum — es sei denn, ihr plant bewusst Zeit für strittige Karten ein.

Praktisch braucht ihr entweder einen physischen Raum mit genug Wandfläche oder ein digitales Whiteboard wie Miro oder FigJam. Remote funktioniert es, aber die Energie ist eine andere als wenn alle vor derselben Wand stehen.

Wann Affinity Mapping glänzt

Projekt-Kickoffs, bei denen das Backlog zum ersten Mal geschätzt wird. Quartals-Planungen, bei denen viele neue Features priorisiert werden müssen. Überall dort, wo ihr schnell einen Überblick braucht und später bei den wichtigsten Stories noch ins Detail gehen könnt.

Ideal für: Backlog Refinement mit 20+ Stories, Projekt-Kickoffs, Situationen in denen Geschwindigkeit wichtiger ist als Präzision.

4. Fibonacci-Sequenz

Die Fibonacci-Sequenz ist streng genommen keine eigene Schätzmethode, sondern die Skala, die bei Planning Poker und anderen Methoden zum Einsatz kommt. Trotzdem lohnt es sich zu verstehen, warum ausgerechnet diese Zahlenreihe so verbreitet ist.

Warum 1, 2, 3, 5, 8, 13 statt einfach 1-10?

Die Antwort liegt in der menschlichen Wahrnehmung von Größenunterschieden. Bei kleinen Aufgaben können wir gut unterscheiden: Eine 2-Punkte-Story ist spürbar mehr Arbeit als eine 1-Punkte-Story. Das Gefühl ist zuverlässig.

Bei großen Aufgaben verschwimmt diese Unterscheidungsfähigkeit. Ist eine Story nun 14 oder 16 Punkte wert? Ehrlich gesagt: Das kann niemand sagen. Die Fibonacci-Sequenz bildet diese abnehmende Präzision ab. Die Sprünge werden größer — von 8 auf 13, von 13 auf 21 — und signalisieren damit: “Ab hier wird’s unsicher.”

Der psychologische Effekt

Wenn jemand bei Planning Poker zwischen 8 und 13 wählen muss (statt zwischen 9 und 10), ist das ein bewusster Sprung. Er zwingt zur Entscheidung: Ist die Story “eher komplex” oder “deutlich komplex”? Das verhindert Scheingenauigkeit und macht die Diskussion ehrlicher.

Varianten der Skala

Nicht jedes Team nutzt die klassische Fibonacci-Reihe:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21 — der Klassiker
• Verdopplung: 1, 2, 4, 8, 16 — noch gröbere Abstufung
• T-Shirt-Mapping: XS=1, S=2, M=3, L=5, XL=8 — Brücke zwischen beiden Welten

Welche Variante ihr nutzt, ist weniger wichtig als Konsistenz. Wechselt nicht mittendrin die Skala — das macht eure Velocity unbrauchbar.

5. #NoEstimates

Die #NoEstimates-Bewegung stellt eine provokante Frage: Was wäre, wenn wir gar nicht schätzen müssten? Der Name ist etwas irreführend — es geht nicht darum, blind ins Blaue zu arbeiten, sondern darum, den Aufwand für Schätzungen zu eliminieren, indem man das Problem anders löst.

Die Grundidee

Statt Stories zu schätzen, werden sie alle auf dieselbe Größe gebracht. Das Ziel: Jede Story sollte in 1-2 Tagen abschließbar sein. Wenn eine Story größer ist, wird sie aufgeteilt — nicht geschätzt.

Die Velocity ist dann einfach die Anzahl abgeschlossener Stories pro Sprint. Keine Punkte, keine Diskussionen über relative Komplexität. “Wir haben letzte Woche 8 Stories geschafft, diese Woche wahrscheinlich auch.”

Warum das funktionieren kann

Der Trick ist: Wenn alle Stories ungefähr gleich groß sind, wird Schätzen überflüssig. Das Team spart sich stundenlange Refinement-Sessions und kann diese Zeit für die eigentliche Arbeit nutzen.

Außerdem erzwingt #NoEstimates etwas, das ohnehin gute Praxis ist: kleine Stories. Eine Story, die in zwei Tagen fertig sein soll, kann nicht vage oder überladen sein. Sie muss klar abgegrenzt und testbar sein. Das verbessert oft die Story-Qualität mehr als jede Schätzmethode.

Die Voraussetzungen

#NoEstimates funktioniert nicht überall. Es braucht ein erfahrenes Team, das intuitiv weiß, wann eine Story “zu groß” ist. Es braucht eine Domain, die sich in kleine, gleichmäßige Stücke schneiden lässt — was bei manchen technischen Themen schwierig ist.

Und es braucht Stakeholder, die damit leben können, dass es keine Punktzahlen gibt. “Wir schaffen etwa 8 Stories pro Woche” ist für manche weniger greifbar als “Wir schaffen 26 Punkte pro Sprint.”

Der Übergang

Manche Teams nutzen #NoEstimates als Ziel, nicht als Startpunkt. Sie beginnen mit Planning Poker, werden über Zeit immer besser darin, Stories klein zu schneiden — und merken irgendwann, dass alle Stories sowieso zwischen 2 und 5 Punkten landen. An dem Punkt wird Schätzen zum Ritual ohne Mehrwert, und der Wechsel zu #NoEstimates ist natürlich.

Ideal für: Erfahrene Teams mit eingespieltem Rhythmus, Kanban-Umgebungen, Teams die bereits konsistent kleine Stories liefern.

Welche Methode passt zu eurem Team?

Die “beste” Methode gibt es nicht — aber die passende für euren Kontext.

Ihr seid ein neues Team, das gerade erst zusammenfindet: → Startet mit T-Shirt Sizes. Die Hürde ist niedrig, ihr könnt sofort loslegen. Nach 2-3 Sprints, wenn ihr euch besser kennt, wechselt zu Planning Poker für präzisere Planung.

Ihr habt ein riesiges Backlog mit 30+ Stories, das sortiert werden muss: → Affinity Mapping. An einem Nachmittag könnt ihr das gesamte Backlog grob durchschätzen. Für die Top-10-Stories macht ihr danach ein detailliertes Planning Poker.

Ihr macht regelmäßig Refinement und wollt verlässliche Velocity: → Planning Poker ist euer Werkzeug. Der Zeitaufwand lohnt sich, weil die Diskussionen Missverständnisse aufdecken und die Schätzungen über Zeit stabil werden.

Ihr seid ein eingespieltes Team, das kleine Stories routiniert abarbeitet: → Probiert #NoEstimates. Wenn eure Stories ohnehin immer ähnlich groß sind und ihr euren Rhythmus kennt, spart ihr euch das Schätzen. Zählt einfach fertige Stories.

Eure Stakeholder wollen konkrete Zahlen für Prognosen: → Planning Poker mit Fibonacci-Skala. Das liefert die Datenbasis für Velocity-Berechnungen und ermöglicht Aussagen wie “Das Backlog hat 80 Punkte, wir brauchen etwa drei Sprints.”

Ihr arbeitet komplett remote: → Planning Poker funktioniert auch digital. Tools wie Miro, Planning Poker Online oder Jira-Plugins machen die verdeckte Wahl einfach. Wichtig: Kameras an, damit ihr Reaktionen seht.

Häufige Schätz-Fehler

Manche Fehler sehe ich in fast jedem Team, das mit Schätzungen anfängt. Die gute Nachricht: Sie sind vermeidbar, wenn man sie einmal verstanden hat.

1. Story Points in Stunden umrechnen

“5 Points = 2 Tage”

Dieser Fehler ist verführerisch, weil Stakeholder nach Terminen fragen und das Team eine vermeintlich einfache Antwort liefern will. Aber genau das zerstört den Sinn von Story Points.

Story Points messen Komplexität, nicht Zeit. Ein Senior-Entwickler schafft 5 Points vielleicht in einem Tag, ein Junior braucht drei — die Komplexität der Story bleibt dieselbe. Sobald das Team anfängt, Points in Stunden umzurechnen, werden Schätzungen zu Commitments. Und dann traut sich niemand mehr, ehrlich zu schätzen.

Was stattdessen hilft: Erkläre Stakeholdern das Konzept der Velocity. “Wir schaffen im Schnitt 26 Punkte pro Sprint. Das Feature hat 40 Punkte, also zwei Sprints.” Das ist eine ehrliche Prognose ohne falsche Genauigkeit.

2. Ohne Referenz-Stories schätzen

“Das fühlt sich nach einer 5 an.”

Ohne Vergleichsbasis sind Zahlen willkürlich. Was heute eine 5 ist, wird morgen eine 3 und übermorgen eine 8 — je nach Tagesform und wer gerade am Tisch sitzt.

Was stattdessen hilft: Etabliere 2-3 Referenz-Stories, auf die sich alle beziehen können. “Die Login-Story war eine 3 — ist diese Story komplexer oder einfacher?” Dokumentiere diese Referenzen, damit sie auch in drei Monaten noch präsent sind.

3. Velocity als Ziel behandeln

“Letzte Woche 40 Points, diese Woche nur 35. Was ist da los?”

Sobald Velocity zum KPI wird, passiert Vorhersehbares: Das Team inflationiert die Schätzungen. Was vorher eine 5 war, wird zur 8. Die Velocity steigt, aber die tatsächliche Produktivität bleibt gleich — nur die Zahlen sehen besser aus.

Velocity ist ein Planungswerkzeug, kein Leistungsindikator. Sie hilft, Prognosen zu machen — nicht, Teams zu bewerten.

Was stattdessen hilft: Nutze Velocity ausschließlich für Planung. Wenn sie schwankt, frag nach den Ursachen (Urlaub? Technische Probleme? Unklare Stories?) — aber bewerte das Team nicht anhand der Zahl.

4. Den Schätzer überstimmen

“Das ist keine 8, das sind höchstens 5.”

Wenn jemand höher schätzt als der Rest, hat das meistens einen Grund. Vielleicht hat er eine technische Hürde gesehen, die anderen nicht aufgefallen ist. Vielleicht kennt er die Codebasis an dieser Stelle besser. Ihn zu überstimmen bedeutet, wertvolle Information zu ignorieren.

Was stattdessen hilft: Frag nach: “Was siehst du, das ich nicht sehe?” Die Diskussion bringt oft entscheidende Details ans Licht. Und wenn sich herausstellt, dass die Bedenken unbegründet waren — gut, dann hat das Team trotzdem etwas gelernt.

5. Perfekte Genauigkeit erwarten

“Warum wurden aus 5 Points 8?”

Schätzungen sind Schätzungen. Sie werden nie perfekt sein. Einzelne Stories werden länger dauern als erwartet, andere kürzer. Das ist normal und kein Zeichen von Inkompetenz.

Was zählt: Über viele Stories hinweg sollte sich das ausgleichen. Wenn systematisch unterschätzt wird, ist das ein Signal — aber einzelne Abweichungen sind der Normalfall.

Was stattdessen hilft: Tracke nicht, wie genau einzelne Schätzungen waren. Schau auf die Velocity über mehrere Sprints: Stabilisiert sie sich? Dann funktioniert das System.

Story Points richtig nutzen

Velocity verstehen

Velocity = Summe der Story Points, die ein Team pro Sprint abschließt.

Beispiel:

• Sprint 1: 24 Points
• Sprint 2: 28 Points
• Sprint 3: 26 Points
• Durchschnitt: 26 Points

Mit dieser Velocity kannst du planen: “Das Backlog hat 130 Points, wir brauchen etwa 5 Sprints.”

Wann ist es fertig? Planbarkeit durch Velocity

Die Frage “Wann ist Feature X fertig?” werden Stakeholder immer stellen — auch wenn wir sie nicht mögen. Relative Schätzungen helfen dabei, eine ehrliche Antwort zu geben.

Warum werden Teams mit der Zeit besser planbar?

Mit jedem Sprint wächst die Erfahrung des Teams:

• Die Velocity stabilisiert sich
• Schätzungen werden genauer
• Der Rhythmus wird berechenbar

Nach 4-6 Sprints kann ein eingespieltes Team seinen Output zuverlässig vorhersagen.

Prognosen über das Backlog

Ist das Backlog priorisiert und geschätzt, ergibt sich die Lieferprognose fast automatisch:

Der Product Owner kann allein durch die Positionierung im Backlog sagen, wann ein Feature wahrscheinlich kommt.

Vorausschauende Sprint-Planung

Ein guter Product Owner hat nicht nur den nächsten Sprint vorbereitet, sondern 2-3 Sprints vorausgeplant:

• Sprint N: Detailliert ausgearbeitet, bereit für Planning
• Sprint N+1: Grob geschätzt, Stories vorbereitet
• Sprint N+2: Themen identifiziert, noch nicht detailliert

Diese Vorarbeit ermöglicht im Sprint Planning schnelle Anpassungen — und gibt Stakeholdern Sicherheit: “Das Feature steht für Sprint N+2 auf der Liste, also voraussichtlich in 6 Wochen.”

Wann ist eine Story zu groß?

Faustregel: 13+ Points = aufteilen

Warum?

• Große Stories sind schwerer einzuschätzen
• Sie blockieren länger den Sprint
• Feedback kommt später

Splitting-Strategien:

• Nach Workflow-Schritten
• Nach Happy Path vs. Edge Cases
• Nach Plattform (Web, Mobile, API)

Mehr dazu im User Story Aufbau Guide.

Einführung im Team

Woche 1-2: Referenz-Stories etablieren

1. Nehmt 5-10 abgeschlossene Stories
2. Sortiert sie nach gefühlter Komplexität
3. Weist Fibonacci-Zahlen zu (1, 2, 3, 5, 8)
4. Dokumentiert diese als Referenz

Woche 3-4: Planning Poker ausprobieren

1. Erste Session: Nur 3-5 Stories
2. Viel Zeit für Diskussion einplanen
3. Bei Abweichungen: Nicht abstimmen, sondern verstehen

Monat 2+: Velocity messen

1. Nach 3-4 Sprints: Durchschnitt berechnen
2. Velocity für Prognosen nutzen
3. Regelmäßig Referenz-Stories aktualisieren

Schätzungen werden nie perfekt sein — und das ist okay. Der Wert liegt nicht in der Genauigkeit einzelner Zahlen, sondern im Gespräch über Komplexität und in der langfristigen Planbarkeit durch Velocity.

Wenn dein Team mit Schätzungen kämpft, liegt es oft an unklaren Stories oder fehlendem Verständnis für relative Komplexität. Ein Agile Coach kann helfen, die richtige Methode zu finden und das Team anzuleiten.