Sprint Planning

Das Sprint Planning ist das erste Meeting im Sprint. Dabei wird die Arbeit für den kommenden Sprint geplant. Es nimmt das gesamte Scrum-Team teil.

Was ist das Sprint Planning?

Bei Scrum beginnt der Sprint mit dem Sprint Planning. Dabei wird die Arbeit für den kommenden Sprint geplant. Am Sprint Planning nimmt das gesamte Scrum-Team teil. Für einen einmonatigen Sprint beträgt die Dauer des Meetings maximal acht Stunden. Wenn das Ziel des Meetings früher erreicht wurde, kann das Meeting auch früher beendet werden.
Im Sprint Planning werden zwei Fragen beantwortet:

  1. WAS ist im Product Inkrement für den Sprint enthalten?
  2. WIE wird die für die Lieferung des Product Inkrements nötige Arbeit erledigt?

Was ist im Product Inkrement für den Sprint enthalten?

Im ersten Teil des Sprint Plannings stellt der Product Owner die Product-Backlog-Einträge für den kommenden Sprint vor. Das Entwicklungsteam stellt Fragen zu den einzelnen Einträgen, sodass es versteht, WAS entwickelt werden soll. Danach wählt das Entwicklungsteam aus den vorgestellten Product-Backlog-Einträgen so viele aus, wie es glaubt in dem Sprint zu schaffen. Dabei sollte die Leistung aus den vergangenen Sprints sowie die Kapazität des Teams des kommenden Sprints berücksichtigt werden.
Die ausgewählten Product-Backlog-Einträge stellen das Sprint Backlog dar.
Zum Schluss formuliert das Scrum-Team das Sprint-Ziel für den kommenden Sprint. Das Sprint-Ziel leitet das Entwicklungsteam während des Sprints und verdeutlicht, warum es das Product Inkrement erstellt.

Es gibt keine festgelegte Form, wie das Sprint Backlog auszusehen hat. Immer wieder gibt es Diskussionen, ob man ein physisches Board, ein elektronisches Board oder beides benutzen soll. Gerade für Scrum-Anfänger empfehle ich immer ein physisches Board mit Post-It Notes.

Wie wird die für die Lieferung des Product Inkrements nötige Arbeit erledigt?

Im zweiten Teil des Sprint Plannings erstellt das Entwicklungsteam einen Plan, wie es die ausgewählten Product-Backlog-Einträge in den Zustand Fertig bringen kann, also fertigstellen kann.
Die Art und Weise ist dabei nicht vorgegeben. In vielen Teams kommen Softwaretools wie z.B. Jira zum Einsatz. Ich selbst sehe solche Tools kritisch, denn oft passiert es, dass das Team sich dann von den Vorgaben des Tools leiten lässt und lediglich Tasks (kleinere Einheiten des jeweiligen Product-Backlog-Eintrags) erfassen. Allzu oft liegt in vielen Teams der Fokus im zweiten Teils des Sprint Plannings auf der Erstellung der Tasks. Genau das sollte man vermeiden.

Der zweite Teil des Sprint Plannings sollte den Charakter eines Workshops haben. Dabei skizziert das Entwicklungsteam für die Product-Backlog-Einträge Lösungsstrategien. Ich starte mit meinen Teams mit einem leeren Flipchart pro Product-Backlog-Eintrag. Dann wird zusammen eine Lösung unter Berücksichtigung von Architektur, Design und den Vorgaben aus dem Product-Backlog-Eintrag erstellt. Zusätzlich kann man kann Dinge, die noch ungeklärt sind, mit einer Warnfarbe kennzeichnen.

Anschließend kann man dann einzelne Tasks von der Lösungsstrategie ableiten und im Sprint Backlog eintragen. Dabei sollte man die Richtlinie berücksichtigen, dass ein Task möglichst immer innerhalb eines Tages abgearbeitet werden kann.
Diese Art und Weise der Durchführung des zweiten Teils des Sprint Plannings hat mehrere Vorteile:

  • Es entsteht ein zusammenhängender Plan für die Lösung
  • Der zweite Teil des Sprint Plannings ist interaktiver als reines Task-Schreiben
  • Ein Bild sagt mehr als 1000 Wörter: Visuelle Elemente verstärken ein gemeinsames Bild der Lösung
  • Höheres Engagement aller Teammitglieder

Nach dem zweiten Teil des Sprint Plannings hat das Entwicklungsteam die Arbeit für die ersten Tage des Sprints in kleinere Einheiten heruntergebrochen. Es ist durchaus möglich, dass man während des Sprints weitere Product-Backlog-Einträge herunterbrechen muss. Wichtig ist nur, dass nach dem zweiten Teil des Sprint Plannings für alle Product-Backlog-Einträge Lösungsstrategien entwickelt wurden.

Am Ende des Sprint Plannings sollte das Entwicklungsteam in der Lage sein, dem Product Owner und dem Scrum Master zu erklären, wie es die geplante Arbeit umsetzen und das Produkt-Inkrement erstellen möchte. Mit einer visualisierten Lösungsstrategie geht das deutlich einfacher als mit Tasks aus einem Softwaretool.

Wenn das Entwicklungsteam merkt, dass es sich zu viel Arbeit in den Sprint genommen hat, kann es die Product-Backlog-Einträge mit dem Product Owner neu aushandeln.

Am Ende des Termins gibt das Entwicklungsteam ein Commitment an den Product Owner ab, d.h. es verpflichtet sich und zeigt den Willen das Sprint-Ziel zu erreichen.

Buch: Scrum erfolgreich anwenden

Das Buch erklärt verständlich, warum und wie dir Scrum in deinem Team hilft, die richtigen Produkte schneller am Markt zu platzieren.

Die Tipps & Tricks aus dem Buch helfen dir und deinem Team Scrum zu verstehen.

buch-scrum-erfolgreich-anwenden

Erfahre mehr über Scrum

In den folgenden Artikeln erfährst du mehr über Scrum.