Zweck
Metapher für dieses Meeting: Design.
Das Team entwickelt eine Lösung für die Backlog Items, die in diesem Sprint tatsächlich implementiert werden.
Am Ende dieses Meetings ist dem Team klar, WIE es die geplanten Funktionalitäten umsetzen will. ( vgl. Sprint Planning Meeting #1)
Grundlagen
Nur das Entwicklerteam definiert eine Lösung. Architekten und andere Personen außerhalb des Teams werden bei Bedarf eingeladen, um beratend zu helfen. Sie treffen aber keine Entscheidungen für das Team und bleiben Gäste bei diesem Meeting.
Zutaten
- Personen, die das Team beraten können, z.B. Fachexperten oder Spezialisten aus anderen Teams
- Selected Product Backlog
- Flipcharts, Marker, Schere, Leim, Post-its, Whiteboard, Farbstifte ...
Was man NICHT tun sollte
- Tasks schätzen
- Aufgaben zuteilen
Ergebnis
- Design der Applikation
- Architekturdiagramme, Zeichnungen, Beschreibungen
- Einige notierte Tasks
- Anhand der Codebasis hat das Team eine klare Vorstellung entwickelt, wie die Backlog Items konkret umgesetzt werden.
Ablauf
- Los geht's mit dem ersten Backlog Item.
- Wurde von allen verstanden, was gewünscht wird? Flipcharts aus dem SprintPlanning Meeting #1 helfen dabei.
Es findet eine ergebnisorientierte Diskussion darüber statt, wie das Backlog Item umgesetzt werden könnte. Diese Fragen helfen dabei:
Welche Schnittstellen müssen wir schreiben?
- Welche Datenbanken werden wir dafür brauchen?
- Welche Architektur ist dafür notwendig?
- Welche Komponenten müssen wir aktualisieren oder neu schreiben?
Ist klar geworden, wie eine Funktionalität wirklich umgesetzt werden wird, geht es mit dem nächsten Backlog Item weiter.
In den letzten 10 Minuten des Meetings schreibt das Team initiale Tasks auf Post-its und hängt sie ans Taskboard. Das schafft einen überblick darüber, womit die Arbeit am nächsten Tag beginnt. Diese Tasks werden nicht geschätzt.
Dauer / Ort
60 Minuten pro Sprintwoche.
Das Sprint Planning #2 findet im Anschluss an das Sprint Planning Meeting #1 möglichst noch am selben Tag statt.