Story Points in Agile: Der vollständige Leitfaden zur relativen Schätzung

Story Points sind eine Maßeinheit, um die Gesamtgröße eines Product-Backlog-Elements oder einer User Story auszudrücken. Sie kombinieren Aufwand, Komplexität und Unsicherheit in einer einzigen relativen Zahl – und sie sind eines der am häufigsten missverstandenen Konzepte in der agilen Welt. Teams, die sie richtig einsetzen, liefern vorhersehbarer. Teams, die sie falsch einsetzen, schaffen Dysfunktionen. Dieser Leitfaden behandelt, wie Story Points tatsächlich funktionieren, wie man sie zuweist, wie sie mit Velocity und Prognosen zusammenhängen und welche Fehler Sie vermeiden müssen.

Schnellantwort: Story Points auf einen Blick

Aspekt	Story Points
Was sie messen	Relative Größe: Aufwand + Komplexität + Unsicherheit kombiniert
Was sie nicht messen	Zeit in Stunden, individuelle Produktivität oder geschäftlicher Wert
Gängige Skalen	Fibonacci (1, 2, 3, 5, 8, 13, 21), Modifizierte Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100)
Wer schätzt	Die Developers im Scrum Team (nicht der Product Owner oder das Management)
Wann schätzen	Während des Product-Backlog-Refinements oder beim Sprint Planning
Primäre Kennzahl	Velocity – die durchschnittlich abgeschlossenen Story Points pro Sprint
Hauptzweck	Sprint-Kapazitätsplanung und Release-Terminprognosen

Was sind Story Points?

Story Points sind eine relative Maßeinheit. Sie lassen sich nicht in Stunden, Tage oder eine feste Zeitspanne umrechnen. Stattdessen drücken sie aus, wie groß ein Arbeitspaket ist im Vergleich zu anderen Arbeiten, die das Team zuvor erledigt hat.

Stellen Sie sich das wie den Vergleich von Entfernungen vor. Sie wissen vielleicht nicht genau, wie viele Kilometer zwei Städte voneinander entfernt sind, aber Sie können mit Sicherheit sagen: „Die Fahrt nach Stadt B ist etwa doppelt so weit wie die Fahrt nach Stadt A." Dieses vergleichende Urteil ist genau das, was Story Points abbilden.

Mike Cohn, der Story Points in den frühen 2000er Jahren populär machte, beschreibt sie als eine Möglichkeit, die Gesamtgröße einer User Story auszudrücken – indem man kombiniert, wie viel Arbeit anfällt, wie komplex die Arbeit ist und wie viel Risiko oder Unsicherheit besteht.

Die drei Dimensionen eines Story Points

Jede Story-Point-Schätzung spiegelt drei Faktoren wider:

1. Aufwand (Arbeitsvolumen)

Wie viel reine Arbeit steckt dahinter? Eine Story, die Änderungen an 15 Dateien erfordert, hat mehr Aufwand als eine, die nur 2 Dateien betrifft, auch wenn beide unkompliziert sind.

2. Komplexität (Schwierigkeitsgrad)

Wie schwierig ist die Arbeit? Eine Story, die einen komplexen Algorithmus oder eine unbekannte Technologie involviert, ist komplexer als eine, die bekannte Muster verwendet, selbst wenn der Codeumfang ähnlich ist.

3. Unsicherheit (Risiko)

Wie viel wissen Sie nicht? Eine Story, die von einer noch nie genutzten Drittanbieter-API abhängt, birgt mehr Unsicherheit als eine, die Ihren eigenen internen Service verwendet, selbst wenn Aufwand und Komplexität gleich erscheinen.

Eine einzelne Story-Point-Zahl vereint alle drei Dimensionen. Deshalb sollten zwei Stories mit dem gleichen Aufwand, aber unterschiedlicher Komplexität unterschiedliche Punktwerte haben. Und deshalb erhält eine Story mit hoher Unsicherheit eine höhere Schätzung, auch wenn der „Happy Path" klein erscheint – denn die Alternativpfade könnten aufwendig sein.

Dimension	Niedrig	Mittel	Hoch
Aufwand	Änderungen an 1-2 Dateien, unkomplizierte Arbeit	Mittlerer Umfang, 5-10 Dateien oder Module	Großer Umfang, querschnittliche Belange
Komplexität	Bekannte Muster, Team hat es schon gemacht	Einige neue Muster, moderate Lernkurve	Unbekannte Technologie, algorithmische Herausforderungen
Unsicherheit	Klare Anforderungen, keine externen Abhängigkeiten	Einige Unbekannte, aber eingegrenzt	Unbekannte mit Unbekannten, Drittanbieter-Risiken

Warum relative Schätzung besser funktioniert als Stunden

Teams, die von Stunden auf Story Points umsteigen, sehen in der Regel innerhalb von 4-6 Sprints eine Verbesserung ihrer Prognosegenauigkeit. Hier ist der Grund:

Menschen sind schlecht im absoluten Schätzen. Wenn ich Sie frage „Wie viele Stunden wird dieses Feature dauern?", hängt Ihre Antwort davon ab, wer die Arbeit macht, welche Unterbrechungen auftreten und wie sich die Anforderungen entwickeln. Forschungen in der kognitiven Psychologie zeigen durchgehend, dass Menschen einfache Aufgaben überschätzen und komplexe Aufgaben unterschätzen, wenn sie in absoluten Einheiten schätzen.

Menschen sind gut im relativen Vergleich. Wenn ich Sie frage „Ist dieses Feature größer oder kleiner als das Login-Feature, das wir letzten Sprint gebaut haben?", können Sie schnell und genau antworten. Der Ankereffekt arbeitet zu Ihren Gunsten – Sie haben einen konkreten Referenzpunkt.

Story Points sind teamspezifisch, und das ist ein Feature. Eine 5-Punkt-Story bei Team A könnte 2 Tage dauern. Die gleiche 5-Punkt-Story bei Team B könnte 4 Tage dauern. Das ist in Ordnung – jedes Team hat seine eigene Velocity, die das spezifische Tempo des Teams berücksichtigt. Man vergleicht Story Points niemals zwischen Teams.

Story Points absorbieren Unsicherheit auf natürliche Weise. Wenn Sie in Stunden schätzen, fühlen Sie den Druck, präzise zu sein: „Das wird genau 6 Stunden dauern." Wenn Sie in Story Points schätzen, ist die Skala bewusst grob: „Das ist ungefähr so groß wie die andere 5-Punkt-Story." Die Grobheit ist beabsichtigt – sie verhindert falsche Präzision.

Story-Point-Skalen

Fibonacci-Skala

Die Standard-Story-Point-Skala folgt der Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 21

Die Abstände zwischen den Zahlen werden mit steigenden Werten größer. Das spiegelt eine fundamentale Wahrheit über das Schätzen wider: Je größer etwas ist, desto weniger präzise kann man es schätzen. Der Unterschied zwischen einer 1-Punkt- und einer 2-Punkt-Story ist bedeutsam und erkennbar. Der Unterschied zwischen einer 20-Punkt- und einer 21-Punkt-Story ist es nicht – weshalb die Fibonacci-Folge von 13 auf 21 springt, anstatt 14, 15, 16, 17, 18, 19, 20 anzubieten.

Modifizierte Fibonacci-Skala

Viele Teams verwenden eine modifizierte Version: 1, 2, 3, 5, 8, 13, 20, 40, 100

Diese ersetzt 21 durch 20 (leichter zu handhaben) und fügt 40 und 100 für sehr große Elemente hinzu, die aufgeteilt werden müssen. Beim Planning Poker enthalten Karten typischerweise 0 (kein Aufwand), ½ (trivial) und Spezialkarten wie ∞ (zu groß) und ? (benötige mehr Informationen).

Zweierpotenzen

Einige Teams verwenden Zweierpotenzen: 1, 2, 4, 8, 16, 32

Diese Skala bietet weniger Auswahlmöglichkeiten, was die Schätzung beschleunigt, aber die Granularität im unteren Bereich verringert. Sie ist weniger verbreitet als Fibonacci, funktioniert aber gut für Teams, die maximale Einfachheit wünschen.

Story Points zuweisen: Schritt für Schritt

Schritt 1: Wählen Sie Ihre Referenz-Story

Wählen Sie eine gut verstandene Story, die das Team bereits abgeschlossen hat. Sie sollte klein bis mittelgroß sein – nicht das Einfachste, was Sie je gemacht haben, und nicht das Komplexeste. Weisen Sie ihr einen Basiswert zu, typischerweise 3 oder 5 Punkte.

Diese Referenz-Story wird zu Ihrem Maßstab. Jede zukünftige Schätzung ist ein Vergleich damit.

Schritt 2: Definieren Sie Ihre Ankerpunkte

Erstellen Sie 3-4 Anker-Stories über die gesamte Skala:

Punkte	Beispiel-Anker	Eigenschaften
1	„Tooltip zu einem bestehenden Button hinzufügen"	Trivialer Aufwand, keine Komplexität, keine Unsicherheit
3	„Neues Feld zu einem bestehenden Formular mit Validierung hinzufügen"	Moderater Aufwand, geringe Komplexität, minimale Unsicherheit
5	„Neuen API-Endpunkt mit Authentifizierung erstellen"	Erheblicher Aufwand, moderate Komplexität, etwas Unsicherheit
8	„Integration mit einem Drittanbieter-Zahlungsdienstleister"	Großer Aufwand, hohe Komplexität, bemerkenswerte Unsicherheit
13	„Benachrichtigungssystem mit Echtzeit-Push neu gestalten"	Sehr großer Aufwand, hohe Komplexität, signifikante Unsicherheit

Schritt 3: Schätzen durch Vergleich

Fragen Sie für jede neue Story: „Wie groß ist das im Vergleich zu unseren Referenz-Stories?"

• „Ist es größer oder kleiner als die 5-Punkt-API-Endpunkt-Story?"
• „Hat es etwa die gleiche Komplexität wie die 8-Punkt-Zahlungsintegration?"
• „Ist es einfacher als die 3-Punkt-Formularfeld-Story?"

Verwenden Sie Planning Poker für die Schätzungssitzung. Jeder Developer wählt gleichzeitig eine Karte, um Anker-Bias zu vermeiden, und dann bespricht das Team die Ausreißer.

Schritt 4: Ausreißer besprechen

Wenn Schätzungen auseinandergehen (z.B. eine Person zeigt 3 und eine andere 13), nicht mitteln – diskutieren. Die Abweichung zeigt fast immer, dass Teammitglieder unterschiedliche Annahmen über Umfang, Herangehensweise oder Risiken haben.

Bitten Sie die Ausreißer, ihre Begründung zu erklären:

• Hochschätzer: „Welches Risiko oder welche Komplexität siehst du, die der Rest von uns nicht sieht?"
• Niedrigschätzer: „Welche Vereinfachung setzt du voraus, die wir wissen sollten?"

Diese Gespräche sind oft der wertvollste Teil der Schätzung – sie decken versteckte Anforderungen auf und schaffen ein gemeinsames Verständnis im Team, bevor die Arbeit beginnt.

Schritt 5: Aufteilungsschwelle festlegen

Legen Sie einen maximalen Punktwert fest, über dem Stories aufgeteilt werden müssen. Die meisten Teams setzen diesen bei 13 Punkten. Alles, was auf 13 oder höher geschätzt wird, wird vor dem Eintritt in einen Sprint in kleinere Stories aufgeteilt.

Warum? Große Stories haben per Definition hohe Unsicherheit. Das Aufteilen reduziert Risiken und verbessert den Arbeitsfluss. Eine 13-Punkt-Story könnte es nicht schaffen, in einem Sprint abgeschlossen zu werden, aber drei 5-Punkt-Stories aus demselben Feature werden wahrscheinlich mindestens zwei davon abgeschlossen sehen.

Story Points und Velocity

Wie Velocity funktioniert

Velocity ist die Gesamtzahl der in einem Sprint abgeschlossenen Story Points. Nur Stories, die die Definition of Done erfüllen, zählen. Teilweise abgeschlossene Stories tragen null zur Velocity bei.

Sprint	Geplante Punkte	Abgeschlossene Punkte	Laufender Durchschnitt
Sprint 1	30	24	24
Sprint 2	28	28	26
Sprint 3	26	22	24,7
Sprint 4	25	27	25,3
Sprint 5	26	25	25,2
Sprint 6	25	26	25,3

Nach 6 Sprints hat dieses Team eine stabile Durchschnittsvelocity von etwa 25 Punkten pro Sprint.

Velocity für die Sprint-Planung nutzen

Während des Sprint Plannings verwendet das Team das Prinzip „Yesterday's Weather" – ihre aktuelle durchschnittliche Velocity – um zu entscheiden, wie viel Arbeit sie in den Sprint aufnehmen. Wenn der Durchschnitt 25 Punkte beträgt, wählen sie ungefähr 25 Punkte an Product-Backlog-Elementen aus.

Velocity ist ein Planungswerkzeug, kein Leistungsmaßstab. Sie sagt Ihnen, wie viel das Team realistisch erreichen kann, damit Sie entsprechend planen können. Sie sagt Ihnen nicht, ob das Team hart genug, schnell genug oder gut genug arbeitet.

Velocity für Release-Prognosen nutzen

Mit stabiler Velocity können Sie Release-Termine prognostizieren:

Verbleibendes Backlog: 100 Story Points Durchschnittliche Velocity: 25 Punkte pro Sprint Sprint-Länge: 2 Wochen Prognose: 4 Sprints (8 Wochen) zur Fertigstellung des verbleibenden Backlogs

Fügen Sie einen Puffer für Unsicherheiten hinzu. Die meisten Teams planen mit 80% ihrer geschätzten Kapazität, was die realistische Prognose auf 5 Sprints (10 Wochen) anhebt.

Für anspruchsvollere Prognosen verwenden Sie einen Velocity-Bereich (Best-Case, Durchschnitt, Worst-Case), um eine Zeitspanne statt eines einzelnen Datums zu liefern. Das gibt Stakeholdern ein ehrlicheres Bild.

Story Points vs. Stunden vs. Ideale Tage

Attribut	Story Points	Stunden	Ideale Tage
Einheitstyp	Relativ	Absolut	Semi-relativ
Was gemessen wird	Größe (Aufwand + Komplexität + Unsicherheit)	Kalenderzeit bis zur Fertigstellung	Tage ununterbrochener Arbeit
Präzision	Bewusst grob (Fibonacci-Skala)	Falsch präzise („genau 6 Stunden")	Moderat („ungefähr 2 ideale Tage")
Personenabhängig	Nein – das Team schätzt gemeinsam	Ja – hängt davon ab, wer die Arbeit macht	Teilweise – „ideal" wird unterschiedlich interpretiert
Velocity-Tracking	Summe der abgeschlossenen Punkte pro Sprint	Summe der aufgewendeten (oder verbleibenden) Stunden	Summe der abgeschlossenen idealen Tage pro Sprint
Am besten für	Sprint-Planung, Release-Prognosen	Aufgaben-Level-Tracking (innerhalb einer Story)	Teams im Übergang von Wasserfall
Größtes Risiko	Punkte als Stunden behandeln	Mikromanagement, „Auslastungs"-Druck	Verwechslung zwischen idealen und tatsächlichen Tagen

Story Points und Stunden können koexistieren. Viele Teams schätzen Stories in Story Points für Planungszwecke und brechen Stories dann während des Sprint Plannings in Aufgaben herunter, die in Stunden geschätzt werden. Die Story-Point-Schätzung beantwortet die Sprint-Level-Frage „Wie viel können wir schaffen?", während die Stundenschätzung die Frage „Wie sollten wir es angehen?" beantwortet.

Schätzungstechniken mit Story Points

Technik	Am besten für	Zeit pro Element	Teamgröße
Planning Poker	Sprint-Level-Verfeinerung von 5-15 Stories	2-5 Minuten	3-9
Affinitätsschätzung	Erstgrößenbestimmung von 50-200 Stories	10-20 Sekunden	5-9
T-Shirt-Größen	Roadmap-Level-Schätzung	15-30 Sekunden	Beliebig
Bucket-System	Großflächige Größenbestimmung von 50-200 Stories	10-30 Sekunden	5-15

Planning Poker ist die am häufigsten verwendete Technik für Story-Point-Schätzungen. Das Team bespricht eine Story, jeder Developer deckt gleichzeitig eine Karte mit seiner Schätzung auf, und die Gruppe nähert sich durch Diskussion einem Konsenswert an.

Praxisbeispiele: Story Points in der Anwendung

SaaS-Produktteam

Ein SaaS-Team mit stabiler Velocity von 32 Punkten pro Sprint (2-Wochen-Sprints) nutzt Story Points, um vierteljährliche Releases zu prognostizieren. Ihre Referenz-Stories umfassen: 1-Punkt-Bugfixes, 3-Punkt-Feature-Anpassungen, 5-Punkt-neue-Features, 8-Punkt-Integrationen und 13-Punkt-Architekturänderungen. Sie teilen alles über 13 auf und verwenden Velocity-Bereiche (28-36) für Release-Terminprognosen.

Mobile-App-Team

Ein Mobile-Team schätzt getrennt für iOS und Android, wenn sich Features erheblich unterscheiden. Ihre 5-Punkt-Referenz-Story ist „einen neuen Bildschirm mit API-Integration und Standard-UI-Komponenten hinzufügen". Sie verfolgen die Velocity pro Plattform und stellten fest, dass iOS durchgehend 15% höhere Velocity aufweist, bedingt durch reiferes Tooling, was sie in die plattformübergreifende Release-Planung einbeziehen.

Data-Engineering-Team

Ein Data-Team verwendet modifizierte Story Points für Pipeline-Arbeit. Ihre Referenz-Stories sind data-pipeline-spezifisch: 2 Punkte für einen neuen Datenquellen-Connector, 5 Punkte für eine Transformations-Pipeline, 8 Punkte für eine systemübergreifende Datenmigration, 13 Punkte für ein neues Analytics-Dashboard mit Echtzeit-Feeds. Sie stellten fest, dass Datenqualitätsprobleme Unsicherheiten verursachen, denen reguläre Feature-Teams nicht ausgesetzt sind, sodass ihre Velocity variabler ist.

Reguliertes Gesundheits-Team

Ein Gesundheits-Team berücksichtigt den Compliance-Aufwand in seinen Story-Point-Schätzungen. Ein Feature, das Patientengesundheitsinformationen (PHI) berührt, erhält automatisch +3 Punkte für HIPAA-Dokumentation, Audit-Protokollierung und Sicherheitsüberprüfung. Ihre Velocity ist niedriger als bei vergleichbaren nicht-regulierten Teams, aber ihre Prognosen sind genau, weil die Compliance-Arbeit in die Schätzungen eingebaut ist.

Enterprise-Plattform-Team

Ein Plattform-Team, das 5 interne Consumer-Teams bedient, verfolgt Story Points, trackt aber auch den Durchsatz (abgeschlossene Stories pro Sprint) als sekundäre Kennzahl. Sie stellten fest, dass ihre Story-Point-Schätzungen inkonsistent waren, weil die Stories von Infrastrukturänderungen bis zur API-Entwicklung reichten, weshalb sie separate Referenz-Stories für jeden Arbeitstyp pflegen und diese während der Planung abgleichen.

Remote-First-Startup

Ein vollständig remote arbeitendes Startup mit 6 Entwicklern nutzt asynchrones Planning Poker über Parabol. Jeder Entwickler überprüft Stories unabhängig, gibt Schätzungen innerhalb eines 24-Stunden-Fensters ab, und nur Stories mit erheblicher Abweichung lösen eine synchrone Diskussion aus. Dieser Ansatz benötigt 30 Minuten synchrone Zeit pro Woche statt der 2 Stunden, die ihr vorheriges Vor-Ort-Planning-Poker erforderte.

Story-Point-Reifegradmodell

Stufe 1: Einstieg (Sprints 1-4)

Merkmale:

• Keine historischen Velocity-Daten
• Schätzungen fühlen sich willkürlich an – „Ist das eine 3 oder eine 5?"
• Team überschätzt oder unterschätzt durchgehend
• Stories werden häufig in den nächsten Sprint übertragen

Worauf Sie sich konzentrieren sollten:

• Etablieren Sie 3-5 Referenz-Stories und verwenden Sie sie in jeder Sitzung
• Machen Sie sich keine Sorgen um Genauigkeit – konzentrieren Sie sich auf Konsistenz
• Verfolgen Sie die Velocity, aber verlassen Sie sich noch nicht darauf

Stufe 2: Kalibrierung (Sprints 5-10)

Merkmale:

• Velocity-Daten entstehen, sind aber verrauscht
• Das Team beginnt, sich schneller auf Schätzungen zu einigen
• Einige Stories überraschen noch (deutlich größer oder kleiner als geschätzt)
• Referenz-Stories werden basierend auf Erfahrung aktualisiert

Worauf Sie sich konzentrieren sollten:

• Vergleichen Sie Schätzungen mit tatsächlichen Ergebnissen in Retrospektiven
• Identifizieren Sie Muster: „Wir unterschätzen durchgehend Stories, die X beinhalten"
• Beginnen Sie, Velocity für die Sprint-Kapazitätsplanung zu nutzen

Stufe 3: Stabil (Sprints 11-20)

Merkmale:

• Velocity ist innerhalb einer 15-20%-Spanne vorhersagbar
• Schätzungssitzungen sind schneller – die meisten Stories konvergieren schnell
• Übertragungen sind selten (weniger als 1 Story pro Sprint)
• Das Team hat ein intuitives Gespür dafür, was jeder Punktwert bedeutet

Worauf Sie sich konzentrieren sollten:

• Verwenden Sie Velocity-Bereiche für Release-Prognosen
• Verfeinern Sie die Aufteilungsschwelle basierend auf Abschlussmustern
• Coachen Sie neue Teammitglieder anhand des Referenz-Story-Katalogs

Stufe 4: Optimiert (Sprint 20+)

Merkmale:

• Velocity-Variationskoeffizient liegt unter 15%
• Schätzung benötigt minimale Zeit – das Team ist sich oft ohne Diskussion einig
• Prognosen sind innerhalb von 10-15% genau
• Das Team beginnt möglicherweise in Frage zu stellen, ob formale Schätzungen noch nötig sind

Worauf Sie sich konzentrieren sollten:

• Erwägen Sie den Umstieg auf durchsatzbasierte Prognosen (#NoEstimates)
• Verwenden Sie Monte-Carlo-Simulation für probabilistische Prognosen
• Konzentrieren Sie die Schätzungszeit nur auf Stories mit hoher Unsicherheit

10 häufige Story-Point-Fehler

Fehler Nr. 1: Story Points als Stunden behandeln

Was passiert: Team oder Management rechnet Punkte in Stunden um („1 Punkt = 4 Stunden"). Eine 5-Punkt-Story wird mit 20 Stunden erwartet.

Warum das schädlich ist: Das zerstört den relativen Charakter von Story Points. Es führt alle Probleme wieder ein, die stundenbasierte Schätzung verursacht – personenabhängige Schätzungen, Druck zur Zeiterfassung und falsche Präzision.

Lösung: Definieren Sie niemals eine Punkt-zu-Stunden-Umrechnung. Wenn jemand fragt „Wie viele Stunden sind eine 5-Punkt-Story?", lautet die korrekte Antwort: „Das hängt davon ab, wer daran arbeitet, was sonst passiert und was wir entdecken. Die Velocity sagt uns, wie viele Punkte das Team pro Sprint abschließt."

Fehler Nr. 2: Velocity über Teams hinweg vergleichen

Was passiert: Das Management rankt Teams nach Velocity: „Team A schafft 40 Punkte pro Sprint und Team B nur 25 – Team B muss sich verbessern."

Warum das schädlich ist: Story Points sind teamspezifisch. „5 Punkte" bei Team A und „5 Punkte" bei Team B messen nicht dasselbe. Sie zu vergleichen ist wie Punktzahlen verschiedener Videospiele zu vergleichen.

Lösung: Die Velocity jedes Teams ist nur für dieses Team aussagekräftig. Wenn Sie teamübergreifende Vergleiche brauchen, verwenden Sie den Durchsatz (Anzahl abgeschlossener Stories) oder die Durchlaufzeit (Zeit von Beginn bis Abschluss), die objektive Maße sind.

Fehler Nr. 3: Story Points als Leistungskennzahl verwenden

Was passiert: Individuelle Velocity wird verfolgt („Sarah hat diesen Sprint 18 Punkte abgeschlossen, aber Carlos nur 12").

Warum das schädlich ist: Es schafft perverse Anreize. Entwickler blähen Schätzungen auf, um produktiver zu wirken. Zusammenarbeit sinkt, weil jemandem zu helfen nicht die persönliche Punktzahl erhöht. Teamvertrauen erodiert.

Lösung: Story Points messen die Teamleistung, niemals die individuelle Leistung. Wenn das Management auf individuellen Kennzahlen besteht, verwenden Sie andere Maße (Code-Review-Beteiligung, Wissensaustausch, Fehlerraten), die das Schätzungssystem nicht verzerren.

Fehler Nr. 4: Bugs und technische Schulden schätzen

Was passiert: Das Team weist Bugs Story Points zu: „Diese Null-Pointer-Ausnahme ist ein 3-Punkt-Bug."

Warum das schädlich ist: Bugs sind von Natur aus unvorhersehbar. Die „Lösung" kann 20 Minuten oder 2 Tage dauern, abhängig von der Ursache. Punkte zuzuweisen erzeugt falsche Vorhersehbarkeit. Und wenn Bugs zur Velocity zählen, werden Teams dazu angereizt, mehr Bugs zu erzeugen (mehr Velocity!).

Lösung: Verfolgen Sie Bugs nach Anzahl, nicht nach Punkten. Verwenden Sie eine separate Kapazitätszuweisung (z.B. „20% der Sprint-Kapazität für Bugs reserviert") anstelle von punktbasierter Planung für Fehlerarbeit.

Fehler Nr. 5: Nie nachschätzen

Was passiert: Eine Story, die während des Backlog-Refinements auf 5 Punkte geschätzt wurde, hat drei Monate später beim Sprint Planning immer noch 5 Punkte, obwohl sich das Verständnis des Teams geändert hat.

Warum das schädlich ist: Frühe Schätzungen werden mit begrenzten Informationen gemacht. Wenn das Team mehr über die Arbeit erfährt, sollte die Schätzung dieses Lernen widerspiegeln.

Lösung: Schätzen Sie während des Sprint Plannings nach, wenn sich das Verständnis des Teams wesentlich geändert hat. Das ist keine Verschwendung – das ist Empirismus.

Fehler Nr. 6: Am Urteil des Product Owners festhalten

Was passiert: Der Product Owner sagt „das sollte einfach sein, vielleicht eine 2 oder 3", bevor das Team schätzt.

Warum das schädlich ist: Die Aufwandseinschätzung des PO verankert das Denken des Teams. Entwickler, die höher geschätzt hätten, fühlen sich nun unter Druck, dem PO zuzustimmen.

Lösung: Der Product Owner präsentiert die Story und beantwortet Fragen, schlägt aber niemals einen Punktwert vor. Nur Developers schätzen. Verwenden Sie gleichzeitiges Aufdecken (Planning Poker), um zu verhindern, dass eine einzelne Person die Gruppe verankert.

Fehler Nr. 7: Zu lange mit dem Schätzen verbringen

Was passiert: Das Team debattiert 15 Minuten lang, ob eine Story eine 5 oder eine 8 ist.

Warum das schädlich ist: Der Präzisionsunterschied zwischen 5 und 8 ist auf lange Sicht minimal – die Velocity absorbiert ihn. 15 Minuten darüber zu debattieren ist reine Verschwendung.

Lösung: Wenn das Team sich nach zwei Runden Planning Poker (etwa 3-5 Minuten) nicht einigen kann, nehmen Sie die höhere Schätzung und machen Sie weiter. Das Gespräch darüber, warum Schätzungen auseinandergehen, ist wichtiger als die endgültige Zahl.

Fehler Nr. 8: Velocity-Druck

Was passiert: Das Management setzt Velocity-Ziele: „Wir müssen diesen Sprint 35 Punkte erreichen."

Warum das schädlich ist: Wenn Velocity zum Ziel wird, hört sie auf, eine nützliche Messgröße zu sein. Teams blähen Schätzungen auf, um das Ziel zu erreichen (Goodharts Gesetz), was die Daten für Prognosen bedeutungslos macht.

Lösung: Velocity ist deskriptiv, nicht präskriptiv. Sie beschreibt, was das Team getan hat, nicht was es tun soll. Manager sollten Velocity nur für Prognosen verwenden, niemals für Zielsetzung.

Fehler Nr. 9: Velocity-Instabilität ignorieren

Was passiert: Die Velocity eines Teams schwankt stark – 18, 35, 22, 40, 15 – aber sie planen mit dem Durchschnitt (26).

Warum das schädlich ist: Hohe Varianz macht den Durchschnitt unzuverlässig. Mit einem unzuverlässigen Durchschnitt zu planen führt zu chronisch verfehlten Prognosen.

Lösung: Verfolgen Sie den Variationskoeffizienten (Standardabweichung / Mittelwert). Liegt er über 25%, konzentrieren Sie sich auf die Stabilisierung der Velocity, bevor Sie sie für Prognosen verwenden. Häufige Ursachen für Instabilität: Umfangsänderungen mitten im Sprint, inkonsistente Teamverfügbarkeit, nicht gut verfeinerte Stories und variierende Definitionen von „Done".

Fehler Nr. 10: Story Points ohne Referenz-Stories verwenden

Was passiert: Jede Schätzungssitzung beginnt von vorn ohne Anker: „Also... ist das eine 5?"

Warum das schädlich ist: Ohne Referenz-Stories driften Schätzungen im Laufe der Zeit ab. Was vor drei Monaten eine 5 war, wird heute zur 3, was Velocity-Trends bedeutungslos macht.

Lösung: Pflegen Sie einen Katalog von 5-8 Referenz-Stories bei wichtigen Punktwerten (1, 2, 3, 5, 8, 13). Überprüfen und aktualisieren Sie den Katalog vierteljährlich. Neue Teammitglieder sollten diese Referenz-Stories studieren, bevor sie an ihrer ersten Schätzungssitzung teilnehmen.

Wann Story Points nicht verwenden

Story Points sind nicht die einzige Option, und sie sind nicht immer die beste:

• Sehr kleine Teams (2-3 Personen): Der Aufwand formaler Schätzung lohnt sich möglicherweise nicht. Diese Teams wissen oft intuitiv, wie viel Arbeit in einen Sprint passt.
• Hochgradig stabile Arbeit: Wenn jede Story ungefähr gleich groß ist (wie ein Support-Team, das Tickets bearbeitet), ist Durchsatzzählung einfacher und ebenso prognosefähig.
• Reife Teams mit stabilem Durchsatz: Einige erfahrene Teams geben Story Points vollständig auf und prognostizieren anhand der Story-Anzahl und historischer Abschlussraten. Dies ist der #NoEstimates-Ansatz.
• Neue Teams ohne Backlog: Wenn Sie keine abgeschlossenen Stories als Referenz haben, sind Story Points bedeutungslos. Beginnen Sie mit T-Shirt-Sizing oder zeitbasierten Schätzungen und wechseln Sie dann nach 3-4 Sprints zu Story Points.

Fazit

Story Points funktionieren, wenn Teams verstehen, was sie tatsächlich messen – relative Größe, nicht Zeit – und sie für ihren vorgesehenen Zweck nutzen: Sprint-Kapazitätsplanung und Release-Prognosen. Sie scheitern, wenn Organisationen sie als Produktivitätskennzahlen behandeln, sie in Stunden umrechnen oder sie zwischen Teams vergleichen.

Wichtige Erkenntnisse:

1. Story Points kombinieren Aufwand, Komplexität und Unsicherheit in einer einzigen relativen Zahl
2. Sie erfordern Referenz-Stories – ohne Baseline driften Schätzungen ab und werden bedeutungslos
3. Die wachsenden Abstände der Fibonacci-Skala spiegeln die inhärente Ungenauigkeit beim Schätzen größerer Arbeit wider
4. Velocity ist die Brücke zwischen Story Points und Planung – sie zeigt, wie viele Punkte das Team tatsächlich pro Sprint liefert
5. Rechnen Sie Story Points niemals in Stunden um, vergleichen Sie Velocity nicht zwischen Teams und verwenden Sie Punkte nicht als Leistungskennzahl
6. Stories, die auf 13+ Punkte geschätzt werden, sollten vor dem Sprint entlang funktionaler Grenzen aufgeteilt werden
7. Schätzungsgespräche sind wichtiger als die endgültige Zahl – abweichende Schätzungen decken verborgene Annahmen auf
8. Reife Teams mit stabilem Durchsatz können Story Points ganz hinter sich lassen – und das ist völlig in Ordnung

Häufig gestellte Fragen (FAQs)