Sprint Planning vs. Backlog Refinement
Sprint Planning und Backlog Refinement sind die beiden Vorbereitungsereignisse, die die Sprint-Qualität bestimmen. Sie zu verwechseln führt zu schlecht geführten Meetings, überkommitierten Sprints und frustrierten Teams.
Kurzreferenz: Hauptunterschiede
| Backlog Refinement | Sprint Planning |
|---|---|
| Laufend während des Sprints (typischerweise 1–2 Sitzungen pro Sprint) | Einmal, zu Beginn jedes Sprints |
| Bereite Backlog-Einträge: geschätzt, Akzeptanzkriterien geschrieben, Abhängigkeiten identifiziert | Sprint Goal + ausgewähltes Sprint Backlog + erste Aufgabenzerlegung |
| Product Owner + gesamtes Team | Scrum Master moderiert; gesamtes Team committed |
Was Backlog Refinement leistet
Refinement bereitet zukünftige Arbeit vor. Seine Outputs — verfeinerte, geschätzte Backlog-Einträge — sind die Inputs für Sprint Planning. Ohne Refinement kann Sprint Planning nicht effizient funktionieren.
Im Refinement können Stories hinterfragt, geändert und entfernt werden. Der Product Owner kann repriorisieren. Das Entwicklungsteam kann Umfang ablehnen.
- Akzeptanzkriterien schreiben und überprüfen
- Große Stories in Sprint-geeignete Einträge aufteilen
- Mit Planning Poker schätzen
- Abhängigkeiten identifizieren und lösen
- Veraltete oder ersetzte Einträge entfernen
Was Sprint Planning leistet
Sprint Planning committed auf einen spezifischen Plan. Die Flexibilität des Refinements verengt sich: der Product Owner hat das Backlog geordnet, das Team hat Kapazitätsdaten.
Die drei erforderlichen Outputs des Sprint Plannings — Sprint Goal, ausgewähltes Backlog und erste Aufgabenzerlegung — sind Commitments.
- Das Sprint Goal vereinbaren
- Backlog-Einträge auswählen, die in die Sprint-Kapazität passen
- Verbleibende ungeschätzte Einträge schätzen (kurz)
- Die ersten 2–3 Arbeitstage in Aufgaben aufteilen
- Das Commitment des Teams bestätigen
Häufige Fehler, die die Grenze verwischen
Die Grenze zwischen Refinement und Planning wird häufig verwischt.
- Schätzen während Sprint Planning: wenn Stories ohne Schätzungen zum Planning kommen, muss das Team schätzen, bevor sie auswählen können. Fix: alle Kandidaten-Stories im Refinement schätzen.
- Akzeptanzkriterien während Planning ändern: wenn der Product Owner Sprint Planning nutzt, um Akzeptanzkriterien zu überarbeiten, kann das Team nicht genau planen.
- Refinement "zur Zeitersparnis" überspringen: eine Stunde Refinement spart zwei bis drei Stunden Planning.
- Planning für Refinement-Diskussionen nutzen: "Warte — was bedeutet diese Story eigentlich?" ist eine Refinement-Frage.
Wie Refinement und Planning zusammenarbeiten
Die Beziehung ist vorgelagert-nachgelagert: Refinement produziert die Inputs, die Planning verbraucht.
- Refinement läuft Sprint-Mitte und verarbeitet das Backlog zwei Sprints im Voraus.
- Stories verlassen das Refinement bereit: geschätzt, Akzeptanzkriterien akzeptiert, Abhängigkeiten gelöst.
- Sprint Planning wählt aus bereiten Stories, vereinbart das Sprint Goal und produziert ein Sprint Backlog.
- Der Sprint produziert Velocity-Daten, die in die Refinement-Priorisierung zurückfließen.
- Der Zyklus wiederholt sich.
Sprint Planning vs. Refinement FAQ
Ist Refinement ein Scrum-Event?
Nein. Der Scrum Guide beschreibt Refinement als Aktivität, nicht als formales Event. Die formalen Scrum-Events sind Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive.
Kann Refinement Sprint Planning ersetzen?
Nein. Refinement bereitet Arbeit vor; Sprint Planning committed auf Arbeit. Du brauchst beides.
Wer moderiert Refinement vs. Sprint Planning?
Beide werden typischerweise vom Scrum Master moderiert. Der Product Owner leitet oft die Refinement-Diskussionen.
Wie wissen wir, ob unser Refinement funktioniert?
Gutes Refinement zeigt sich im Sprint Planning: weniger Klärungsfragen, schnellere Story-Auswahl und Planning-Sitzungen, die pünktlich enden.
Nutze kostenloses Online-Planning-Poker für Schätzungen beim Refinement