Zweck

Metapher für dieses Meeting: Analyse.

Das Entwicklungsteam soll genau verstehen, WAS der End User funktional möchte.

Am Ende dieses Meetings ist das Team in der Lage selbst zu entscheiden, was und wie viel es in diesem Sprint liefern will.

Grundlagen

Ausschließlich Mitglieder des Entwicklungsteams entscheiden, wie viele Backlog Items in den Sprint aufgenommen werden.

Zutaten

• Ein geschätztes und priorisiertes Product Backlog
• Flipcharts, Marker, Schere, Leim, Post-its, Whiteboards, Farbstifte u.ä.
• Urlaubsplan, Kontaktdaten wichtiger Personen für Nachfragen

Tipp für den Product Owner: Manchmal starten diese Meetings schleppend.

Ein Uhrenvergleich oder die Ansage, wo der Notausgang ist, schaffen eine wachsamere, aktionsgeladene Atmosphäre.

Dauer / Ort

60 Minuten pro Woche (Wo) des Sprints.

Praktischerweise findet das Meeting vormittags statt, dann kann man das Sprint Planning Meeting #2 am Nachmittag desselben Tages anschließen.

Ergebnis

• Selected Product Backlog
• Anforderungen für jedes Backlog Item
• User Acceptance Tests für jedes Backlog Item

Ablauf

1. Los geht's mit dem ersten Product Backlog Item (Story).
2. Die Anforderungen der Story werden vom Entwicklungsteam erfragt und geklärt.
3. Die User Acceptance Test(s) werden vom Entwicklungsteam erstellt.
4. Die Constraints, d.h. technische Auflagen und Bedingungen, werden festgehalten.
5. Die Abnahmekriterien werden festgelegt.
6. Der Level of Done für diese Story wird festgelegt.
7. Hilfreich ist eine Skizze der Funktionalität.
8. Mit dem nächsten Backlog Item genauso vorgehen.

Prozess-Check

Der ScrumMaster fragt das Team nach einigen Stories: "Wollen wir die bis jetzt besprochenen Stories in diesem Sprint erledigen?"

5 Minuten Pause.

Dann geht's weiter mit dem nächsten Backlog Item.

Den Prozess beenden

1. Stopp circa 20 Minuten vor dem Ende der Timebox des Sprint Planning #1.
2. Der ScrumMaster fragt noch mal, jetzt ernster: "Wollen wir das 1. Backlog Item schaffen, das 2. ...?"
3. Gibt es zu einer Story keine eindeutige Zustimmung zur Lieferbarkeit, war die vorherige Story die letzte, zu der sich das Team verpflichtet hat.
4. Jetzt ein wichtiger Schritt: den Product Owner rausschicken! Das Team muss unbeeinflusst entscheiden können. Außer ScrumMaster und Team verlassen auch alle anderen Anwesenden (Customer, End User etc.) den Raum.
5. Wenn das Team allein ist, wird noch einmal ausdrücklich gefragt: "Ist das die Liste der Dinge, die wir in diesem Sprint schaffen wollen?"
6. Hoffentlich gibt es jetzt noch eine kurze, offene Diskussion über den Inhalt des kommenden Sprints.
7. Das Ergebnis wird dem Product Owner und dem End User kommuniziert.Keine Diskussion darüber führen!

Was man NICHT tun sollte

1. Stories oder Tasks schätzen.
2. Die Frage nach dem Können stellen: Könnt ihr diese Stories schaffen?