Im Planungsmeeting werden feste Rollen verteilt (hauptsächlich zur Trennung von Geschäftsverantwortung und technischer Verantwortung) und mit Hilfe von diversen Spielzügen ein Entwicklungsplan aufgestellt.

Spielziel ist es, einen Plan zu erstellen, zu dem die Entwickler mit Überzeugung stehen können und der dem Kunden den mit den vorhandenen Mitteln bestmöglich erreichbaren Geschäftswert liefert.

grober Ablauf

1. Der Kunde notiert AnforderungsGeschichten, die kurz die gewünschten Features des Systems beschreiben. Die Entwickler helfen ihm dabei, diese möglichst unabhängig von der später zur Umsetzung benutzten Technik zu formulieren.
2. Die Entwickler schätzen den Aufwand für jede einzelne AnforderungsGeschichte in idealen Wochen.
1. Lassen sich Stories nicht im Bereich von 1 bis 3 idealen Wochen schätzen, so müssen diese sinnvoll gesplittet bzw. zusammengelegt werden.
2. Haben die Entwickler aus technischen Gründen Schwierigkeiten, eine AnforderungsGeschichte zu schätzen, so wird eine SpikeSolution angesetzt, um den technischen Aspekt näher zu beleuchten.
3. Die Entwickler geben ihre erwartete EntwicklungsGeschwindigkeit? bekannt.
4. Der Kunde legt mit Hilfe der gewonnen Informationen einen ReleasePlan? fest, der ihm den größten Geschäftswert bringt. Dabei darf er nicht mehr Aufwand pro Iteration planen, als die EntwicklungsGeschwindigkeit? festlegt.

Ein großer Zyklus ist z.B. ein Release z.B. mit drei Monaten Entwicklungszeit. Dieses Release wird mit dem PlanungsSpiel oder der ReleasePlanung (engl. Planning Game) geplant. Elemente der Planung sind die Stories oder Features und deren Priorisierung und Schätzung.

Ein kleiner Zyklus betrifft eine Iteration oder ein minor Release mit einer Dauer von 1 bis 4 Wochen - IterationsPlanung? (engl. IterationPlanning?). Hier geht es um die Aufspaltung der Stories in Aufgaben (tasks) und deren Aufwandsschätzungen.

• /Diagramm
• /Diskussion
• WardsWiki:PlanningGame