Story Points vs. Zeit – Schätzen Sie noch in Stunden – und wundern sich trotzdem über verfehlte Deadlines und genervte Teams? Oder arbeiten Sie bereits mit Story Points, kämpfen aber mit Missverständnissen im Management?
In vielen Unternehmen prallen zwei Welten aufeinander: klassische Zeitplanung vs. agile, relative Schätzung. Dieser Artikel zeigt Ihnen praxisnah, wie Sie „Story Points vs Zeit“ sinnvoll zusammenbringen, typische Fehler vermeiden und verlässlich planen – ohne die Vorteile agiler Methoden zu verlieren.
1. Grundlagen: Was sind Story Points – und was ist Zeit?
Was sind Story Points?
Story Points sind eine relative Maßeinheit, mit der agile Teams den Aufwand für eine User Story bewerten. Berücksichtigt werden typischerweise:
- Komplexität
- Umfang
- Risiken und Unsicherheiten
- Abhängigkeiten
Wichtig:
- Story Points messen keine Stunden.
- Sie vergleichen Aufgaben untereinander, nicht gegen die Uhr.
Eine Story mit 5 Story Points ist für das Team ungefähr doppelt so „schwer“ wie eine mit 2–3 Story Points – unabhängig von der tatsächlichen Bearbeitungszeit in Stunden.
Was bedeutet „Zeit“ in der Planung?
Mit „Zeit“ meinen Unternehmen meist:
- Kalenderzeit (z. B. bis Ende Q2)
- Arbeitszeit (Stunden, Tage, Personentage)
- Termine und Deadlines (Milestones, Releases, Go-Live-Daten)
Zeitbasierte Schätzung beantwortet Fragen wie:
- Wie lange dauert diese Aufgabe?
- Wann ist das Feature voraussichtlich fertig?
- Reicht die Kapazität des Teams für dieses Quartal?
2. Warum Story Points entstanden sind (und klassische Stundenschätzung scheitert)
Klassische Schätzung in Stunden wirkt intuitiv – gerade für Führungskräfte. In der Praxis führt sie aber oft zu:
- Scheingenauigkeit: „16 Stunden“ klingt präzise, ist aber meist geraten.
- Schätzstress im Team: Langwierige Diskussionen über 8 vs. 10 Stunden.
- Schuldzuweisungen: „Du hast doch 2 Tage geschätzt, warum dauert es 4?“
- Fehlende Lernkurve: Kaum systematisches Feedback auf Schätzqualität.
Story Points adressieren genau diese Probleme:
- Fokus auf relative Einschätzung statt vermeintlicher Exaktheit.
- Schnellere Schätzrunden, weniger Konflikte.
- Bessere Prognosen über mehrere Sprints hinweg (Velocity).
- Mehr Akzeptanz, dass Unsicherheit dazugehört – vor allem in Wissensarbeit.
3. Story Points vs Zeit – der Kernunterschied in einem Satz
Story Points messen relativen Aufwand, Zeit misst Kalendereinheiten.
Oder anders formuliert:
- Story Points: „Wie schwer ist diese Aufgabe relativ zu anderen?“
- Zeit: „Wie lange wird das voraussichtlich dauern, wenn unser Team so arbeitet wie bisher?“
Beide Größen haben ihre Berechtigung – sie beantworten unterschiedliche Fragen.
4. Vorteile von Story Points in der Praxis
4.1 Bessere Vorhersagbarkeit über mehrere Sprints
Einzelne Stories sind schwer zu schätzen. Über mehrere Sprints entsteht jedoch ein Muster:
- Das Team erledigt pro Sprint im Schnitt 30–40 Story Points.
- Neue Stories werden relativ zu bekannten Stories bewertet.
- Über mehr Sprints glätten sich Ausreißer.
So entsteht eine Velocity, mit der sich planen lässt:
„Mit unserer aktuellen Velocity von rund 35 Story Points pro Sprint benötigen wir für dieses Epic mit 210 Story Points ungefähr 6 Sprints.“
4.2 Weniger emotionale Debatten
Anstatt:
- „Du brauchst doch keine 3 Tage für das Feature.“
heißt es:
- „Fühlt sich diese Story eher wie die 5-Punkte-Story von letzter Woche an oder wie die 8-Punkte-Story vom letzten Sprint?“
Das:
- reduziert persönliche Angriffe
- stärkt Teamverantwortung
- fördert Lernen über Vergleich statt über Rechtfertigung
4.3 Besserer Umgang mit Unsicherheit
Story Points erlauben, Unsicherheit explizit einzupreisen:
- Hohe technische Risiken?
- Abhängigkeiten von anderen Teams?
- Neues System, unbekannte Domäne?
Solche Faktoren schlagen sich direkt in höheren Story Points nieder – ohne zu behaupten, man könne exakte Stunden kennen.
5. Nachteile und Missverständnisse rund um Story Points
Story Points sind kein Wundermittel. Viele Organisationen nutzen sie falsch – und sind dann frustriert.
Typische Probleme:
- Verwechslung mit Zeit: 1 Story Point = 1 Tag. Das zerstört den Zweck.
- Velocity als Zielvorgabe: „Ihr müsst nächsten Monat 20 % mehr Story Points liefern.“
- Teamübergreifende Vergleiche: „Team A schafft mehr Story Points als Team B.“
Diese Missverständnisse untergraben Vertrauen und Motivation. Entscheider sollten verstehen:
Story Points dienen dem Team zur Prognose, nicht als Controlling-Kennzahl im Sinne eines Leistungsbenchmarks zwischen Teams.
6. Wie Story Points und Zeit sauber zusammenhängen
Viele Führungskräfte stellen zurecht die Frage:
„Wann ist was fertig? Ich kann mit Story Points alleine nichts anfangen.“
Der Schlüssel ist die Kombination aus:
- Story Points zur Schätzung des Backlogs
- Velocity zur Ableitung von Dauer (Story Points → Sprints → Kalenderzeit)
- Kapazitätsplanung in Personenzeit pro Sprint
6.1 Vom Backlog zur Dauer – in 4 Schritten
- Backlog in Story Points schätzen
- Alle relevanten User Stories bewerten (z. B. Planning Poker).
- Summe der Story Points für ein Ziel-Release bestimmen.
- Team-Velocity bestimmen
- Über 3–6 Sprints beobachten, wie viele Story Points real fertig wurden.
- Realistische Spanne ableiten, z. B. 30–40 Story Points/Sprint.
- Sprints kalkulieren
- Gesamtpunkte / mittlere Velocity = benötigte Sprints.
- Beispiel: 240 SP / 35 SP ≈ 7 Sprints.
- Kalenderzeit ableiten
- 7 Sprints à 2 Wochen → rund 14 Wochen.
- Puffer für Urlaube, Feiertage, Abhängigkeiten ergänzen.
So entsteht eine zeitliche Prognose, ohne Story Points in Stunden zu „übersetzen“.
7. Wichtige W-Fragen zu Story Points vs Zeit
Was ist besser: Story Points oder Zeitschätzung?
Die praxisnahe Antwort:
- Für Detailplanung einzelner Tage: Stunden / Personentage.
- Für Produkt- und Releaseprognosen: Story Points plus Velocity.
Beides gehört zusammen. Wer nur eines nutzt, verschenkt Potenzial.
Kann man Story Points in Stunden umrechnen?
Sie sollten es nicht direkt tun, aber Sie können aus Erfahrung Bandbreiten ableiten, etwa:
- „Unser Team erledigt im Schnitt 35 Story Points pro Sprint.
Ein Sprint entspricht netto rund 8 Personentagen pro Teammitglied.“
Daraus ergibt sich indirekt ein Zusammenhang – auf Teamebene, nicht auf Story-Ebene.
Versuchen Sie nicht:
- 1 Story Point = 4 Stunden
- 3 Story Points = 1 Tag
Das führt zu Micromanagement und zerstört die Vorteile relativer Schätzung.
Wie lange dauert 1 Story Point?
Die ehrlichste Antwort:
Das hängt vom Team ab – und sogar innerhalb eines Teams schwankt es.
Ein Team mit hoher Erfahrung, stabiler Umgebung und wenig Störungen liefert in der gleichen Zeit mehr Story Points als ein junges Team in einer komplexen Umgebung. Und das ist völlig in Ordnung.
8. Praxisbeispiele: Wenn Story Points vs Zeit schiefgeht
Beispiel 1: Management will direkte Stundenübersetzung
Situation:
- Team arbeitet mit Story Points.
- Management fordert: „Wir brauchen Story Points in Stunden, sonst können wir nicht steuern.“
- Ergebnis: 1 SP = 0,5 Tage wird festgelegt.
Folgen:
- Diskussionen verschieben sich zurück auf Stundenniveau.
- Team fühlt sich kontrolliert und unter Druck gesetzt.
- Schätzungen werden politisch: Man passt Punkte an Erwartungen an.
Besser:
- Velocity und reale Durchlaufzeiten zeigen.
- Prognosen für Releases immer als Bandbreite kommunizieren.
- Story Points als Team-internes Werkzeug respektieren.
Beispiel 2: Velocity als KPI zur Leistungsmessung
Situation:
- Zwei Teams, beide schätzen in Story Points.
- Management vergleicht Velocity:
- Team A: 50 Story Points pro Sprint
- Team B: 30 Story Points pro Sprint
- Schlussfolgerung: Team A ist „effizienter“.
Problem:
- Jedes Team hat seine eigene Kalibrierung.
- Ein 5-Punkte-Ticket in Team A kann einem 8-Punkte-Ticket in Team B entsprechen.
- Teams fangen an, Punkte zu „optimieren“, nicht Ergebnisse.
Besser:
- Teams nicht anhand von Story Points vergleichen.
- Outcome und geschaffenen Business Value betrachten.
- Velocity nur zur internen Planung und Prognose nutzen.
9. Konkreter Leitfaden: Wie Sie Story Points und Zeit erfolgreich kombinieren
Schritt 1: Klare Ziele je Ebene definieren
- Team-Ebene:
- Arbeitsplanung, Fokus, realistische Commitments
- Werkzeug: Story Points, Velocity, Task-Board
- Management-Ebene:
- Portfoliosteuerung, Budgetrahmen, Roadmap
- Werkzeug: Epics, Release-Plan, Kapazitätsplanung in Sprints und Quartalen
Entscheidend:
Nicht jede Management-Frage braucht eine Stundenangabe. Oft reichen Bandbreiten in Sprints.
Schritt 2: Einheitliche Schätzpraxis im Team etablieren
- Gemeinsame Referenz-Stories definieren („Kalibrierungs-Stories“).
- Fibonacci-Skala nutzen (z. B. 1, 2, 3, 5, 8, 13, 20).
- Maximalgröße festlegen (z. B. alles >13 muss gesplittet werden).
- Planning Poker oder ähnliche Techniken einsetzen.
Ziel:
Ein stabiles, geteiltes Verständnis von „klein“, „mittel“, „groß“.
Schritt 3: Velocity nachhaltig aufbauen
- Über mindestens 3–6 Sprints konsequent messen:
- Wie viele Story Points wurden „Done“?
- Ausreißer analysieren:
- Woran lag es?
- Was können wir verbessern?
- Mit realistischen Spannen planen, nicht mit Best-Case-Werten.
Schritt 4: Release- und Roadmap-Planung auf Story-Point-Basis
- Größere Einheiten (Epics, Features) ebenfalls in Story Points schätzen.
- Summe pro Release / Quartal erfassen.
- Mit durchschnittlicher Velocity in Sprints umrechnen.
- Puffer für bekannte Risiken und Abhängigkeiten ergänzen.
Kommunikation nach oben:
- „Mit aktueller Velocity und Risikoprofil erwarten wir das Release zwischen Sprint 6 und 8.“
- Keine Scheinpräzision: Kein exaktes Datum ohne klare Grundlage.
Schritt 5: Transparente Kommunikation an Stakeholder
- Story Points erklären, ohne zu sehr zu technisieren:
- „Wir nutzen eine relative Größe, ähnlich wie T-Shirt-Größen.“
- Ergebnisse immer in Zeitbandbreiten übersetzen:
- „voraussichtlich im Zeitraum Mai bis Mitte Juni“.
- Annahmen offenlegen:
- Teamstabilität, Urlaubsplanung, Abhängigkeiten.
10. Typische Fehler bei „Story Points vs Zeit“ – und wie Sie sie vermeiden
Story Points als Controlling-Kennzahl missbrauchen
- Lösung: Story Points gehören in die Teamverantwortung, Management steuert über Ziele, Outcomes und Termine – nicht über Punkte.
Einmalige Umrechnung Story Points → Stunden
- Lösung: Nur über Team-Velocity und Kapazität in Sprints denken, nicht über fixe Punkt-Stunden-Formeln.
Überdetaillierte Schätzung in frühen Phasen
- Lösung: Grobe Schätzungen in Story Points für Epics / Features; Detailierung nahe an der Umsetzung.
Kein Umgang mit Unsicherheit
- Lösung: Bandbreiten planen („zwischen 5 und 7 Sprints“), Risiken separat benennen, keine Versprechen ohne Puffer.
Teamübergreifende Vergleiche von Story Points
- Lösung: Teams an ihren eigenen Trends messen; teamübergreifend auf Business-Ergebnisse und Durchlaufzeiten achten.
11. Empfehlung: Wann Story Points, wann Zeit?
Sie können sich an folgenden Leitlinien orientieren:
Nutzen Sie primär Story Points, wenn:
- Sie Backlogs, Epics oder Features priorisieren.
- Sie die grobe Dauer eines Releases einschätzen wollen.
- Sie mehrere Sprints im Voraus planen.
- Sie mit wechselnder Komplexität und Unsicherheit arbeiten.
Nutzen Sie primär Zeit (Stunden / Tage), wenn:
- Sie Tagesplanung und individuelle Verfügbarkeit organisieren.
- Sie abhängige Termine koordinieren (z. B. Schulungen, Marketing, Rollout).
- Sie vertragliche Rahmenbedingungen (z. B. Festpreis, SLAs) erfüllen müssen.
Wichtig ist nicht „Story Points vs Zeit“, sondern eine klare Trennung der Anwendungsfälle.
12. Checkliste: So bringen Sie Story Points und Zeit in Ihrem Unternehmen zusammen
Nutzen Sie diese Liste als schnellen Praxis-Check:
- Wir haben ein gemeinsames Verständnis von Story Points im Team.
- Wir nutzen eine einheitliche Schätzskala (z. B. Fibonacci).
- Wir haben Referenz-Stories zur Kalibrierung.
- Wir messen unsere Velocity über mehrere Sprints.
- Wir planen Releases in Sprints und Zeitbandbreiten, nicht in exakten Daten ohne Grundlage.
- Wir übersetzen Story-Point-Planung verständlich in Zeit für Stakeholder.
- Management vergleicht keine Teams über Story Points.
- Story Points werden nicht als harte Leistungskennzahl missbraucht.
- Wir passen unsere Planung an, wenn Velocity sich dauerhaft verändert.
- Wir kommunizieren Risiken und Unsicherheiten offen.
13. Fazit: Story Points vs Zeit ist kein Entweder-oder
Story Points und Zeit konkurrieren nicht – sie ergänzen sich.
- Story Points helfen Teams, Aufwand und Unsicherheit realistisch einzuschätzen.
- Zeit bleibt die Sprache von Budgets, Roadmaps und Führungsgremien.
- Die Kunst besteht darin, beide Welten sauber zu verbinden, ohne in Scheingenauigkeit oder Controlling-Fallen zu rutschen.
Wenn Sie als Entscheider, Projektmanager oder Führungskraft verstehen,
- wofür Story Points gedacht sind,
- wie Sie daraus verlässliche Zeitprognosen ableiten,
- und welche Missverständnisse Sie unbedingt vermeiden sollten,
schaffen Sie den Rahmen, in dem agile Teams wirklich liefern können – und Sie trotzdem planbar steuern.
Benötigen Sie Unterstützung dabei, Story Points, Velocity und Zeitplanung in Ihrem Unternehmen pragmatisch aufzusetzen oder zu verbessern?
Die Beraterinnen und Berater der PURE Consultant begleiten Sie von der ersten Analyse bis zur etablierten agilen Planungsroutine – fachlich fundiert, praxisnah und auf Ihre Organisation zugeschnitten.