Das Planning Game

XPs Planning Game basiert auf einem einfachen Prinzip: Das Business entscheidet, was gebaut wird. Entwickler entscheiden, wie es gebaut wird.

Diese Trennung ist entscheidend:

• Das Business versteht Wert, Priorität und Timing. Es weiß, welche Features für Kunden wichtig sind und wann sie benötigt werden.
• Entwickler verstehen Aufwand, Komplexität und technische Einschränkungen. Sie wissen, was schwierig und was einfach ist.

Keiner kann die Aufgabe des anderen übernehmen. Das Business kann den technischen Aufwand nicht schätzen. Entwickler können keine Business-Prioritäten festlegen. Das Planning Game bringt beide mit klaren Rollen zusammen.

Das Business wählt:

• Welche Features gebaut werden
• In welcher Reihenfolge sie gebaut werden
• Wann sie veröffentlicht werden

Entwickler liefern:

• Schätzungen für jedes Feature
• Technische Optionen und Trade-offs
• Risikobewertungen

Release-Planung beantwortet: Was wird im nächsten Release enthalten sein und wann wird es ausgeliefert?

XP sagt, dass Sie zwei dieser drei Variablen fixieren können:

• Umfang: Welche Features enthalten sind
• Zeitplan: Wann das Release ausgeliefert wird
• Ressourcen: Wer daran arbeitet

Sie können nicht alle drei fixieren. Etwas muss flexibel bleiben.

Release mit festem Datum: „Wir liefern am 1. März aus. Wie viel können wir schaffen?" Der Umfang ist verhandelbar.

Release mit festem Umfang: „Wir brauchen diese Features. Wann können wir sie ausliefern?" Das Datum ist verhandelbar.

Der Planning-Game-Prozess:

1. Das Business listet gewünschte Features in Prioritätsreihenfolge auf
2. Entwickler schätzen jedes Feature
3. Basierend auf der Velocity wird berechnet, wie viele Features bis zum Datum passen (oder wie lange der Umfang dauert)
4. Das Business passt Prioritäten bei Bedarf an
5. Verpflichtung zu einem Plan, aber mit der Erwartung, neu zu planen

Planen Sie regelmäßig neu. Wenn Sie mehr lernen, aktualisieren Sie den Release-Plan. XP geht nicht davon aus, dass der ursprüngliche Plan heilig ist.

Iterationsplanung ist detaillierter. Sie findet zu Beginn jeder Iteration statt (normalerweise wöchentlich oder zweiwöchentlich).

Der Prozess:

1. Das Business präsentiert die höchstpriorisierten Stories für die Iteration
2. Entwickler zerlegen Stories in Tasks (2-4 Stunden Blöcke)
3. Entwickler melden sich für Tasks basierend auf Interesse und Fähigkeiten
4. Das Team verpflichtet sich zu dem, was es in dieser Iteration abschließen wird

Wichtige Regeln:

• Nur das Business setzt Prioritäten
• Nur Entwickler schätzen und verpflichten sich
• Nicht zu viel verpflichten (Puffer für Unerwartetes lassen)
• Technische Arbeit (Infrastruktur, Refactoring) in den Plan einbeziehen

Während der Iteration:

• Fortschritt sichtbar verfolgen (Kanban-Board, Burndown)
• Bei Abweichung sofort ansprechen
• Keinen Umfang während der Iteration hinzufügen (Fokus schützen)
• Bei Vorsprung die nächste Story einplanen

Iterationsplanung ist leichtgewichtiger als Release-Planung. Stories sind bereits geschätzt. Der Fokus liegt auf der Zerlegung in Tasks und der Verpflichtung zu realistischen Mengen.

Pläne ändern sich. XP erwartet dies und baut Anpassung ein.

Wann anpassen:

• Schätzungen waren falsch (Story war größer als erwartet)
• Prioritäten haben sich geändert (Kunde hat neue Anforderungen entdeckt)
• Team-Kapazität hat sich geändert (Krankheit, Fluktuation)
• Externe Abhängigkeiten sind gescheitert (API nicht bereit)

Wie anpassen:

1. Problem sofort transparent machen
2. Auswirkung quantifizieren (wir sind 2 Stories im Rückstand)
3. Optionen vorschlagen (Umfang reduzieren, verlängern oder Qualität reduzieren—aber niemals Qualität)
4. Business entscheidet (es besitzt die Priorität)

Was sich nie ändert: Qualität. XP tauscht Qualität nicht gegen Umfang oder Zeitplan. Wenn Sie im Rückstand sind, liefern Sie weniger—nicht schlechter.

Das Planning Game geht von kontinuierlicher Anpassung aus. Der ursprüngliche Plan ist ein Ausgangspunkt, keine Verpflichtung zu einem exakten Ergebnis. Wie Kent Beck sagt: „Der Zweck der Planung ist das Planen, nicht der Plan."

Das Planning Game erfordert einen Kunden—jemanden, der Business-Prioritäten vertritt.

Das könnte sein:

• Der tatsächliche Endnutzer (ideal, aber selten)
• Ein Product Owner (Scrum-Terminologie)
• Ein Product Manager
• Ein Business Analyst

Der Kunde muss:

• Verfügbar sein, um Fragen zu beantworten (idealerweise täglich)
• Prioritätsentscheidungen schnell treffen
• Trade-offs akzeptieren, wenn sich Dinge ändern
• Akzeptanzkriterien für Stories bereitstellen

XPs „On-Site Customer" bedeutete ursprünglich jemanden, der physisch beim Team anwesend ist. In modernen verteilten Teams könnte „on-site" „auf Slack" oder „im Daily Standup" bedeuten. Der Schlüssel ist Verfügbarkeit, nicht physische Anwesenheit.

Ohne Kunden scheitert die Planung. Entwickler raten bei Prioritäten. Der Umfang wuchert, weil niemand entscheidet, was draußen bleibt. Das Team baut das Falsche.