Sprintplanung: agile Best Practices

Grundlagen der Planung

Gute Sprint-Planung folgt einer klaren Struktur. Das Team wertet die letzten Sprints aus, schätzt die eigene Kapazität realistisch ein und formuliert die Ziele eindeutig. Mehr dazu: IT-Projektmanagement-Software für IT-Teams.

1. Mit der Vorbereitung sollte man früh beginnen. Der Product Owner bereitet das Backlog spätestens einen Tag vor dem Termin vor und priorisiert es. Das Entwicklungsteam sollte die User Stories vorher lesen und Rückfragen stellen können.
2. Die klassische Faustregel: zwei Stunden Planung pro Sprintwoche. Bei einem zweiwöchigen Sprint sind das vier Stunden. In der Praxis funktioniert es aber oft besser, diese Zeit auf mehrere kürzere Sitzungen zu verteilen, statt ein einziges langes Meeting abzuhalten.

Vorbereitungsphase

Ohne gründliche Vorbereitung lässt sich die Sprint-Planung nicht verbessern. Diese Phase wird oft unterschätzt, obwohl von ihr der Erfolg des ganzen Prozesses abhängt.

• Definition of Ready (DoR) legt fest, wann eine User Story bereit für einen Sprint ist. Jede Story braucht klare Akzeptanzkriterien, eine Komplexitätsschätzung und bekannte Abhängigkeiten zu anderen Aufgaben. Wird die DoR nicht eingehalten, gerät die Planung ins Chaos. Das Team klärt dann Anforderungen, statt die Umsetzung zu planen.
• Backlog refinement gehört regelmäßig in den Kalender und nicht nur kurz vor die Sprint-Planung. Üblich ist es, dafür 10% der Sprintzeit einzuplanen. Teams können mehrmals pro Woche kurze Refinement-Sitzungen abhalten und die Stories für kommende Sprints Schritt für Schritt ausarbeiten.
• Velocity-Analyse zeigt, wie viel ein Team tatsächlich liefern kann. Der Durchschnitt der letzten 3-5 Sprints ist dabei nur ein Teil des Bildes. Genauso wichtig ist, was den kommenden Sprint bremsen könnte: geplanter Urlaub, Feiertage, aufgelaufene technische Schulden oder externe Abhängigkeiten.

Planungssitzungen

Die Sprint-Planung hat zwei Teile. Zuerst wird entschieden, was im Sprint geliefert wird, danach, wie die ausgewählte Arbeit umgesetzt wird. Beide Teile brauchen andere Informationen und liefern andere Ergebnisse, und wer sie vermischt, schwächt beide.

1. Das Team legt zusammen mit dem Product Owner das Sprintziel fest, das alle ausgewählten User Stories verbindet. Das Ziel sollte spezifisch und messbar sein und für alle Beteiligten einen Sinn ergeben. Schwaches Ziel: "Benutzererfahrung verbessern." Gutes Ziel: "Benutzer können sich mit einem Klick über soziale Medien registrieren."
2. Das Entwicklungsteam zerlegt die ausgewählten Stories in Aufgaben und schätzt sie in Stunden. Dabei kommen versteckte Komplexität und Abhängigkeiten ans Licht, die auf Story-Ebene nicht zu sehen sind. Keine Aufgabe sollte länger als 8 Stunden dauern. Was diese Grenze überschreitet, wird weiter in Unteraufgaben aufgeteilt.

Rollen und Verantwortlichkeiten

Eine gute Sprint-Planung setzt voraus, dass jeder Teilnehmer seine Rolle kennt und sich an ihre Grenzen hält.

• Der Scrum Master moderiert, achtet auf die Timeboxen und hilft dem Team, zu Entscheidungen zu kommen. Lösungen gibt er nicht vor. Er stellt die richtigen Fragen und sorgt dafür, dass die Diskussion bei der Sache bleibt.
• Der Product Owner ist für die Priorisierung des Backlogs verantwortlich und entscheidet, welche Funktionen zuerst umgesetzt werden. Er muss den Geschäftswert jeder Story erklären und die Fragen des Entwicklungsteams so konkret beantworten können, dass eine Schätzung möglich ist.
• Das Entwicklungsteam verpflichtet sich, die Ergebnisse zu liefern. Diese Zusage muss aus dem Team selbst kommen. Wird sie von außen vorgegeben, fehlt etwas: Eine selbst gegebene Zusage motiviert deutlich stärker und schafft mehr Verantwortungsgefühl als ein auferlegtes Ziel.

Häufige Fehler

• Der häufigste Fehler bei der Sprint-Planung ist, die eigene Kapazität zu überschätzen. Teams nehmen sich regelmäßig mehr vor, als sie schaffen können, vor allem am Anfang eines Projekts oder nach einem gut gelaufenen Sprint. Die Regel lautet: lieber weniger zusagen und mehr liefern. Nicht gehaltene Zusagen kosten das Vertrauen der Stakeholder und drücken die Motivation des Teams auch in den folgenden Sprints.
• Fehlende Zeitpuffer sind ein schwerer struktureller Fehler. Ein Sprintplan sollte 10-20% Pufferzeit für unvorhergesehene Aufgaben, Bugs und Supportanfragen enthalten. Diese Reserve füllt man nicht vorab mit zusätzlichen Stories. Sie ist für die ungeplante Arbeit da, die in jedem Sprint anfällt.
• Wer Abhängigkeiten ignoriert, erzeugt Blocker mitten im Sprint. Alle externen Abhängigkeiten müssen bei der Planung erkannt und geklärt werden. Hängt eine Aufgabe von einem anderen Team oder einem externen Dienstleister ab, werden die Termine vorher abgestimmt und die Zusagen vor Sprintbeginn eingeholt.

Prozessüberwachung

In reifen agilen Teams wird auch der Planungsprozess selbst laufend verbessert. In der Retrospektive geht es deshalb um mehr als die Ergebnisse des Sprints. Auch die Qualität der Planung kommt als eigene Einflussgröße auf den Tisch.

Metriken zur Analyse:

• Schätzungsgenauigkeit — geplanter und tatsächlicher Zeitaufwand pro Story und Aufgabe im Vergleich
• Prozentsatz der abgeschlossenen Stories — Anteil der zugesagten Stories, die bis Sprintende geliefert wurden
• Anzahl der Änderungen im Sprint nach der Planung — zeigt, wie stabil die Planung und wie klar die Anforderungen sind
• Zeit, die für die Planung aufgewendet wird — im Vergleich zum Standardwert, um dauerhaft zu viel oder zu wenig Aufwand zu erkennen

Burndown-Diagramme zeigen den Fortschritt im Sprint und machen Probleme so früh sichtbar, dass man noch gegensteuern kann. Zeigt das Diagramm, dass das Team die geplante Arbeit nicht schaffen wird, muss gehandelt werden: Die restlichen Aufgaben werden neu priorisiert oder die User Stories mit der niedrigsten Priorität fliegen aus dem Sprint.

Anpassung der Planung

• Remote-Teams brauchen eine angepasste Sprint-Planung. Passende Tools für die Zusammenarbeit müssen vorhanden sein, und es braucht aktives Bemühen, damit alle Remote-Teilnehmer gleichermaßen zu Wort kommen. In verteilten Teams bringen mehrere kürzere Sitzungen statt eines langen Meetings erfahrungsgemäß mehr Beteiligung und bessere Ergebnisse.
• Große Programme mit mehreren Teams brauchen Abstimmung auf Programmebene. Scrum of Scrums oder SAFe (Scaled Agile Framework) bieten Strukturen, um die Sprint-Planung von Teams mit gemeinsamen Abhängigkeiten aufeinander abzustimmen.
• Wartungsprojekte, in denen ein großer Teil der Sprintzeit in Support und Fehlerbehebung fließt, brauchen eine feste Kapazitätsreserve für ungeplante Arbeit. Üblich ist es, 30-50% der Sprintkapazität für Support einzuplanen und den Rest für neue Funktionen zu nutzen. Wird Support dagegen als Nebenbei-Aufwand statt als geplante Kapazität behandelt, platzen Liefertermine.

Verwandte Artikel:

Für Projektmanagement-Frameworks und Beschränkungsbalance lesen Sie Das Projektmanagement-Dreieck: Umfang, Zeit und Kosten balancieren.

Einen praktischen Überblick über Kanban-Boards und visuelles Workflow-Management finden Sie in Was ist ein Kanban-Board? Ein Leitfaden für visuelles Workflow-Management.

Wie Agile-Teams mit Personas nah an den echten Bedürfnissen der Nutzer bleiben, lesen Sie in Agile-Personas: Verbesserung der benutzerzentrierten Entwicklung in Agile-Projekten. Weitere Informationen: Kanban-Board.

Fazit

Eine wirksame Sprint-Planung braucht einen systematischen Ansatz und ständige Verbesserung. Sie ist eine bewusste Gewohnheit und keine Pflichtübung am Projektende. Das Werkzeug dafür ist die Retrospektive: Dort schaut das Team auf die Ergebnisse des Sprints und auch auf die Planungsentscheidungen, die zu ihnen geführt haben. So wird die Planung selbst derselben schrittweisen Verbesserung unterzogen, die Agile auf das Produkt anwendet.