Was vorher fertig sein muss
Ein klar formuliertes Product Goal als Outcome-Aussage liegt vor und ist mit der Geschäftsstrategie abgestimmt.
Ein cross-funktionales, stabiles Team mit Working Agreements, Definition of Done und benannten Verantwortlichkeiten (PO, Scrum Master, Developers) ist gebildet.
Was vor Start vorliegen muss
Backlog-Tool (Jira, Linear, GitHub Projects); Sprint-Board (Kanban-Spalten); Whiteboard für Sprint Planning; Definition of Done als sichtbares Dokument; Kalender für wiederkehrende Events; Retrospektive-Tool.
Ein Product Owner (Backlog-Ordnung, Maximierung Wert); ein Scrum Master (Prozessschutz); 3-9 Developers (cross-funktional, liefern Increment); Stakeholder als Reviewer im Sprint Review.
Product Goal; aktuelles Product Backlog mit Priorisierung; Definition of Done; geplante Sprint-Länge (1-4 Wochen, 2 Wochen typisch); Kapazitätsschätzung des Teams; Stakeholder-Verfügbarkeit für Reviews.
Laufend, pro Sprint: 2 h Planning, 15 min Daily, 1 h Review, 1 h Retro pro 2-Wochen-Sprint
Kalender-Serie für alle 5 Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Sprint-Board eingerichtet. Definition of Done sichtbar. Stakeholder-Einladung für Review-Termine.
Die eine Frage, die diese Methode beantwortet
Welches inkrementell lieferbare, wertvolle Sprint-Ziel verfolgt das Team in den nächsten 1-4 Wochen, und wie passt es das Vorgehen anhand der Sprint-Ergebnisse an?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Sprint Planning | 2 h für 2-Wochen-Sprint | Drei Teile: (1) Warum dieses Sprint? Sprint Goal aus Product Goal ableiten. (2) Was? Backlog-Items auswählen, die das Sprint Goal liefern. (3) Wie? Plan grob skizzieren, Spitzen identifizieren. | Ohne Sprint Goal wird die Auswahl beliebig. Sprint Goal ist eine Outcome-Aussage, nicht eine Sammlung von Tickets. Wenn das nicht in einen Satz passt, ist der Sprint zu unfokussiert. |
2Phase 2: Sprint-Arbeit und Daily Scrum | 1-4 Wochen, Daily 15 min | Team arbeitet täglich am Sprint Goal. Daily Scrum am gleichen Ort, zur gleichen Zeit, max 15 min: was hilft uns heute das Sprint Goal zu erreichen? Hindernisse benennen. | Daily ist kein Statusreport an den Scrum Master oder PO. Wer drei Sätze pro Person als Pflicht fordert, hat den Zweck verfehlt. Ziel ist Anpassung, nicht Berichterstattung. |
3Phase 3: Sprint Review | 1 h für 2-Wochen-Sprint | Increment vor Stakeholdern zeigen (Demo, nicht Slides). Feedback einholen. Backlog anpassen. Markt- oder Strategie-Updates aufnehmen. Review ist Arbeitssitzung, kein Show-and-Tell. | Wenn Stakeholder nur Beifall klatschen, fehlt Feedback-Substanz. Konkrete Fragen vorbereiten („was würde dich abhalten, das morgen zu nutzen?“). |
4Phase 4: Sprint Retrospective | 1 h für 2-Wochen-Sprint | Was lief gut, was nicht, was ändern wir? Maximal 1-2 konkrete Verbesserungen pro Retro, mit Owner und Erfolgskriterium. Eine Verbesserung wandert ins nächste Sprint Backlog. | Wenn die Retro nur Sammlung ohne Action wird, sterben Verbesserungen. Mindestens eine konkrete Aktion pro Retro, getrackt im nächsten Sprint. |
5Phase 5: Backlog Refinement (laufend) | 10% der Sprint-Kapazität | Product Owner pflegt Backlog: priorisiert, schreibt Items neu, ergänzt Akzeptanzkriterien. Team hilft bei Klärung und Schätzung. Ziel: nächste 1-2 Sprints sind ready. | Backlog ohne Refinement führt zu unklaren Sprint Plannings. Wenn Items mehr Diskussion als Schätzung brauchen, sind sie nicht ready. |
Was am Ende rauskommt
Product Backlog (priorisiert, gepflegt), Sprint Backlog pro Sprint mit Sprint Goal, Increment am Sprint-Ende (releasebar nach DoD), Retrospektive-Action-Items, Sprint-Review-Notizen mit Feedback und Folge-Backlog-Updates.
Product Backlog wächst und schrumpft kontinuierlich, getrackt im Tool. Pro Sprint eigener Sprint-Eintrag mit Goal, Backlog, Burndown (optional), Review-Notes, Retro-Outcomes. Definition of Done versioniert (separates Dokument), Updates als bewusste Entscheidung des Teams.
Kompakte Arbeitsvorlage für Scrum mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Scrum Arbeitsvorlage
## Ziel
Iteratives Framework für komplexe Produktentwicklung mit kurzen Sprints, festen Rollen und definierten Events.
## 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
- Product Backlog:
- Sprint Backlog:
- Increment:
- Sprint Goal:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Sprint 23 — Discovery-Team (12.05.-23.05.2026)
**Sprint Goal**: Onboarding-Schritt 3 ist in 3 Mini-Schritte aufgeteilt und A/B-getestet mit 50% Traffic.
**Sprint Backlog**:
- Story #481: Schritt 3 splitten (8 SP). Owner @lisa.
- Story #482: A/B-Test-Setup im Frontend (5 SP). Owner @ben.
- Story #483: Analytics-Events für 3 Mini-Schritte (3 SP). Owner @anna.
- Story #484: Feature-Flag für Rollout (2 SP). Owner @ben.
**Sprint Review (23.05.2026)**:
- Demo: 3 Mini-Schritte live in Staging, A/B-Test seit Mi mit 10% Traffic.
- Feedback @julia (CPO): „Schritt 2 nimmt zu viel Platz. Anpassen vor 50%-Rollout.“
- Backlog-Update: Story #491 (Schritt-2-Layout) für Sprint 24.
**Retrospektive**:
- Gut: Daily-Fokus auf Sprint Goal, weniger Side-Tasks.
- Schlecht: Code Review-Lag von 18 h im Schnitt.
- Action: Review-SLA 4 h tagsüber, Owner @ben, Erfolg gemessen in Sprint 24.
**DoD-Status**: 4 von 4 Stories done. Increment in Staging, Production-Rollout in Sprint 24 nach Layout-Fix.Symptome erkennen, gegensteuern
Sprint enthält 9 unrelated Stories, niemand kann das Ziel in einem Satz nennen.
Pflicht: Sprint Goal als Outcome-Satz in jedem Sprint Planning. Stories werden danach ausgewählt, nicht umgekehrt. Wenn kein Goal findbar, Sprint nicht starten.
Daily dauert 25 min, jeder berichtet drei Sätze an Scrum Master, keine Anpassung sichtbar.
Daily strikt 15 min, Fokus auf Sprint Goal. Statusupdates ins Tool. Daily ist Anpassungsereignis, nicht Reporting.
Retro produziert Liste an Beobachtungen, nichts ändert sich im nächsten Sprint.
Maximal 1-2 Actions pro Retro, mit Owner und Erfolgskriterium. Eine Action im Sprint Backlog des nächsten Sprints. Bei Nicht-Erfüllung in nächster Retro thematisieren.
PO setzt Sprint Backlog im Alleingang, Developers haben kein Mitspracherecht über das Wie.
Klare Rollenteilung: PO über Was und Reihenfolge, Developers über Wie und Kapazität. Sprint Planning ist gemeinsame Verhandlung. Scrum Master moderiert Rollenkonflikte.
Stories werden als done markiert, Release-Pipeline schlägt fehl, Tester finden Lücken.
DoD als konkrete Checkliste (Tests grün, Doku aktualisiert, deployed in Staging, akzeptanz-getestet). DoD ist Teamentscheidung, Verschärfung im Quartalsreview.
Review ist Slidedeck statt Live-Demo, Stakeholder geben kein Feedback.
Live-Demo am Increment. Stakeholder mit konkreten Fragen aktivieren („würden Sie das morgen nutzen?“). Feedback in Backlog überführen.
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.