Was vorher fertig sein muss
Pro zu schätzendem Item liegen Akzeptanzkriterien vor, sodass Scope und Definition of Done klar sind.
Was vor Start vorliegen muss
Schätz-Tool (Planning Poker, Miro, Linear/Jira mit Story-Point-Feld); Referenzstory-Liste sichtbar; Skala-Plakat (typisch Fibonacci 1, 2, 3, 5, 8, 13, 20); Backlog-Items mit Beschreibung und Kriterien.
Ein Moderator (Scrum Master oder Tech Lead); ein Product Owner für Scope; das umsetzende Team (3-9 Personen); ein Scribe für Annahmen, falls nötig.
Referenzstories aus realer Liefer-Historie mit gesetzten Punkten; gemeinsame Skala-Definition (z. B. „1 = trivial, 13 = größer Story unter Splitting-Verdacht“); Definition of Done.
1-5 min je Item, typisch 60-90 min für Refinement-Session
Referenzstories als Anker an Wand oder Board sichtbar (z. B. „3 = SSO Google, 5 = API-Endpoint Mandanten-Export, 8 = Self-Service-Portal-Teil“). Skala-Plakat. Regel ansagen: Punkte umfassen Umfang, Komplexität, Risiko und Unsicherheit, nicht nur Zeit.
Die eine Frage, die diese Methode beantwortet
Wie groß ist dieses Item relativ zu unseren Referenzstories unter Berücksichtigung von Umfang, Komplexität, Risiko und Unsicherheit?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Referenzstories kalibrieren | 10 min | Referenzstories pro Punktwert durchgehen. Team bestätigt oder korrigiert. Neue Teammitglieder erhalten Erklärung pro Wert. | Ohne Kalibrierung sind Punkte teamintern bedeutungslos. Bei Teamwechsel (>30% neu) Referenzen neu setzen, nicht alte beibehalten. |
2Phase 2: Item-Schätzung | 2-5 min je Item | Item vorstellen, Fragen klären, Schätzung (Planning Poker oder direkt). Punkte beziehen sich auf relative Größe gegenüber Referenz, nicht auf Stunden. | Wenn jemand fragt „wie viele Stunden sind das?“, Methode wurde nicht verstanden. Geduldig erklären: Punkte sind relative Komplexitätseinheit, Velocity macht später Forecasting möglich. |
3Phase 3: Große Items splitten | 5-10 min je Item | Items mit 13+ Punkten als Splitting-Kandidaten markieren. Pro Item Vorschlag mit Owner und Frist. Items über 20 Punkte ohne Split gehen nicht in Sprint. | Große Punkte sind nicht falsch, aber riskant. Splitting reduziert Unsicherheit und erlaubt feinere Velocity-Vorhersage. Wer nicht splitten kann, hat unklares Lösungsverständnis. |
4Phase 4: Velocity-Auswertung | 10 min | Nach Sprint-Ende erledigte Punkte pro Sprint dokumentieren. Velocity der letzten 3-5 Sprints als Range (z. B. „22-31 Points/Sprint“). Forecasting mit dieser Range, nicht mit Mittelwert. | Velocity ist teamintern. Niemals zur Team-Vergleichung nutzen, sonst werden Punkte inflationiert. Velocity-Trend bei Teamwechsel oder Tech-Migration neu kalibrieren. |
Was am Ende rauskommt
Backlog-Items im Ticket-System mit Story-Point-Feld, Referenzstory-Liste im Wiki, Velocity-Verlauf als einfaches Chart pro Sprint, Splitting-Vereinbarungen pro großem Item.
Story Points pro Item gepflegt. Re-Estimation als Kommentar mit Datum und Grund. Velocity-Historie als Sprint-Log mit Punkt-Summe und Sprint-Datum. Referenzstory-Liste mit Änderungsdatum.
Kompakte Arbeitsvorlage für Story Points mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Story Points Arbeitsvorlage
## Ziel
Relative Einheit zur Schätzung von Umfang, Komplexität, Risiko und Unsicherheit von Backlog Items.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Point Estimates:
- Reference Stories:
- Velocity Data:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Story Points - Team Discovery, Skala-Kalibrierung 2026-05-18
**Skala**: 1, 2, 3, 5, 8, 13, 20
**Referenzstories**
- 1: Tooltip-Text-Update (trivial, kein Test).
- 2: Konfig-Toggle für Feature-Flag.
- 3: SSO Google-Anbindung (existierende Library, Doku vorhanden).
- 5: API-Endpoint Mandanten-Export (JSON+CSV, Pagination).
- 8: Self-Service-Portal-Teilstück (UI plus Backend, ein Mandanten-Pfad).
- 13: Multi-Tenant-Mandantenverwaltung (komplexes Datenmodell, mehrere Endpoints).
- 20: Migration Datenbank-Engine (Splitting-Verdacht, vor Sprint zerlegen).
**Sprint 22 Refinement**
- DATEV-Import-Validierung: 5 Points.
- Empfehlungsprompt im Dashboard: 2 Points.
- Webhook-System Basis: 8 Points.
- KI-Belegerkennung Spike: 3 Points (Discovery, kein Implementation).
**Velocity (letzte 4 Sprints)**: 24, 28, 26, 31. Range 24-31, Forecast für Sprint 23 mit unterem Wert (24) als Commitment, oberem (31) als Stretch.Symptome erkennen, gegensteuern
Stakeholder fragt „wie viele Stunden ist ein Punkt“, Team gibt Antwort, Methode wird Zeitschätzung mit Buntpapier.
Punkte als relative Komplexität verteidigen. Zeitprognosen kommen aus Velocity-Range, nicht aus Punkt-zu-Stunde-Umrechnung. Stakeholder-Edukation einmal pro Quartal.
Management vergleicht Velocity zweier Teams („Team A liefert 30, Team B nur 20“), Druck zur Punkt-Inflation entsteht.
Punkte sind teamintern. Vergleich macht keinen Sinn und produziert Inflation. Management-Edukation und Velocity-Reporting nur intern.
Niemand kann mehr sagen, was eine „5er-Story“ aussieht, Schätzung wird Bauchgefühl.
Pro Quartal Referenzen prüfen und aktualisieren. Bei Teamwechsel früher. Referenzen aus realer Liefer-Historie wählen, nicht aus Theorie.
Velocity-Schnitt wird zur Liefer-Zusage, Team unter Druck bei normalen Sprint-Schwankungen.
Velocity als Range kommunizieren, nicht als Punktwert. Forecasts mit Perzentilen (z. B. „85% Wahrscheinlichkeit, in 4 Sprints fertig“). Schwankungen als normal akzeptieren.
Punkte werden Personen zugeordnet, individuelle Velocity gemessen.
Punkte sind Team-Eigenschaft, nicht persönlich. Individuelle Velocity-Messung zerstört Team-Schätzung und führt zu Gaming.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.