Das Sprint Planning beantwortet drei Fragen: Wozu dient dieser Sprint (Sprint-Ziel), was wird ausgewählt, und wie wird die Arbeit erledigt. Ergebnis sind Sprint-Ziel und Sprint Backlog. Die Auswahlmenge bestimmen allein die Entwickler — der Product Owner bestimmt die Reihenfolge.
Die drei Fragen
- 01Wozu dient dieser Sprint?Der Product Owner erläutert, welches Ziel dieser Sprint verfolgt. Daraus entsteht gemeinsam das Sprint-Ziel — ein Satz, kein Aufgabenkatalog.
- 02Was wird ausgewählt?Die Entwickler wählen aus dem geordneten Backlog aus, was sie zum Ziel beitragen können. Der Product Owner erklärt und priorisiert, wählt aber nicht aus.
- 03Wie wird es erledigt?Die Entwickler planen den Weg — Aufgaben, Reihenfolge, Zusammenarbeit. Dieser Teil gehört ihnen allein.
Die Trennung in Schritt zwei ist der Kern und wird laufend verletzt. Der Product Owner darf jederzeit sagen, was ihm am wichtigsten ist. Wie viel davon in den Sprint passt, entscheiden die Entwickler. Wo diese Grenze fällt, werden Sprint-Zusagen bedeutungslos — man verpflichtet sich dann zu etwas, das man nicht selbst eingeschätzt hat.
Das Sprint-Ziel
Das Sprint-Ziel ist das am häufigsten weggelassene Element und das nützlichste. Ohne Ziel ist ein Sprint eine Liste, und die Frage, was bei knapper Zeit wegfallen kann, hat keine Antwort ausser der Reihenfolge im Backlog.
Mit Ziel funktioniert die Abwägung: Was auf das Ziel einzahlt, bleibt; was nicht, geht zurück. Ein brauchbares Sprint-Ziel beschreibt eine Wirkung, nicht eine Menge — «Anträge lassen sich am Ende dieses Sprints vollständig online einreichen» statt «Stories 14, 17 und 22 fertig».
Könnten Sie das Ziel erreichen, wenn eine der ausgewählten Aufgaben wegfiele? Wenn nein, ist es kein Ziel, sondern eine Aufzählung. Ein Ziel muss Spielraum lassen, sonst hilft es bei der Abwägung nicht.
Kapazität realistisch ansetzen
Die verfügbare Kapazität ist nie die nominelle. Abzuziehen sind Ferien und Abwesenheiten, Anteile für Support und Störungen, die Scrum-Ereignisse selbst sowie ein Anteil für Unvorhergesehenes. In der Praxis bleiben von einer Vollzeitwoche etwa fünfundsechzig bis fünfundsiebzig Prozent für Sprint-Arbeit.
Teams, die mit hundert Prozent planen, verfehlen ihre Zusagen strukturell — und lernen daraus meist die falsche Lehre, nämlich dass Schätzungen unzuverlässig seien. Zuverlässiger ist die gemessene Velocity der letzten drei bis fünf Sprints; sie enthält all diese Abzüge bereits.
Warum Plannings zu lang dauern
| Symptom | Tatsächliche Ursache | Wo zu lösen |
|---|---|---|
| Einträge werden erst jetzt verstanden | Refinement zu knapp | Refinement |
| Endlose Schätzdiskussionen | Anforderung unklar, nicht Schätzung strittig | Refinement |
| Auswahl wird verhandelt | Product Owner greift in die Menge ein | Rollenklärung |
| Technische Konzeption im Planning | Zu grosse Einträge | Backlog-Schnitt |
Alle vier Zeilen zeigen dasselbe: Das Planning ist der Ort, an dem sich Versäumnisse zeigen, nicht der, an dem sie entstehen. Ein Team, das die Planning-Dauer senken will, muss am Refinement arbeiten — Zeitlimits im Planning selbst verschieben das Problem nur in den Sprint.
Zeitrahmen
Scrum setzt maximal acht Stunden für einen Monatssprint an, entsprechend weniger bei kürzeren. Bei zweiwöchigen Sprints sind also bis zu vier Stunden zulässig — eingespielte Teams mit gepflegtem Backlog brauchen typischerweise ein bis zwei.
Die Obergrenze ist ein Maximum, kein Richtwert. Wer sie regelmässig ausschöpft, sollte das als Befund lesen und nicht als Normalzustand.
Häufige Fragen
- Was passiert im Sprint Planning?
- Es beantwortet drei Fragen: Wozu dient dieser Sprint (Sprint-Ziel), was wird aus dem Backlog ausgewählt, und wie wird die Arbeit erledigt. Ergebnis sind das Sprint-Ziel und das Sprint Backlog.
- Wer entscheidet, wie viel in einen Sprint passt?
- Ausschliesslich die Entwickler. Der Product Owner bestimmt die Reihenfolge im Backlog und erklärt die Inhalte, aber nicht die Menge. Wo diese Grenze fällt, werden Sprint-Zusagen bedeutungslos.
- Warum dauert unser Sprint Planning so lange?
- Fast immer wegen zu knappem Refinement. Werden Einträge erst im Planning verstanden, geschätzt und geschnitten, verlagert sich die Refinement-Arbeit dorthin. Zeitlimits im Planning lösen das nicht, sie verschieben es in den Sprint.