The Planning Game

XP's planning game is built on a simple principle: Business decides what to build. Developers decide how to build it.

This separation is critical:

• Business understands value, priority, and timing. They know which features matter to customers and when they're needed.
• Developers understand effort, complexity, and technical constraints. They know what's hard and what's easy.

Neither can do the other's job. Business can't estimate technical effort. Developers can't decide business priority. The planning game brings them together with clear roles.

Business chooses:

• Which features to build
• What order to build them
• When to release

Developers provide:

• Estimates for each feature
• Technical options and trade-offs
• Risk assessments

Release planning answers: What will be in the next release and when will it ship?

XP says you can fix two of these three variables:

• Scope: What features are included
• Schedule: When the release ships
• Resources: Who's working on it

You can't fix all three. Something has to flex.

Fixed date release: "We ship on March 1. How much can we get done?" Scope is negotiable.

Fixed scope release: "We need these features. When can we ship them?" Date is negotiable.

The planning game process:

1. Business lists desired features in priority order
2. Developers estimate each feature
3. Based on velocity, calculate how many features fit by the date (or how long to complete the scope)
4. Business adjusts priorities if needed
5. Commit to a plan, but expect to re-plan

Re-plan regularly. As you learn more, update the release plan. XP doesn't assume the initial plan is sacred.

Iteration planning is more detailed. It happens at the start of each iteration (usually weekly or bi-weekly).

The process:

1. Business presents the highest-priority stories for the iteration
2. Developers break stories into tasks (2-4 hour chunks)
3. Developers sign up for tasks based on interest and skill
4. The team commits to what they'll complete this iteration

Key rules:

• Only business sets priority
• Only developers estimate and commit
• Don't over-commit (leave slack for the unexpected)
• Include technical work (infrastructure, refactoring) in the plan

During the iteration:

• Track progress visibly (kanban board, burndown)
• If off-track, raise it immediately
• Don't add scope mid-iteration (protect focus)
• If ahead, pull in the next story

Iteration planning is lighter than release planning. Stories are already estimated. The focus is on breaking into tasks and committing to realistic amounts.

Plans change. XP expects this and builds in adaptation.

When to adjust:

• Estimates were wrong (story was bigger than expected)
• Priorities changed (customer discovered new requirements)
• Team capacity changed (illness, turnover)
• External dependencies failed (API not ready)

How to adjust:

1. Surface the problem immediately (transparency)
2. Quantify the impact (we're 2 stories behind)
3. Propose options (descope, extend, or reduce quality—but never quality)
4. Business decides (they own priority)

What never changes: Quality. XP does not trade quality for scope or schedule. If you're behind, you ship less—not sloppier.

The planning game assumes continuous adjustment. The initial plan is a starting point, not a commitment to an exact outcome. As Kent Beck says: "The purpose of planning is planning, not the plan."

The planning game requires a customer—someone who represents business priorities.

This could be:

• The actual end-user (ideal but rare)
• A product owner (Scrum terminology)
• A product manager
• A business analyst

The customer must:

• Be available to answer questions (ideally daily)
• Make priority decisions quickly
• Accept trade-offs when things change
• Provide acceptance criteria for stories

XP's "on-site customer" originally meant someone physically present with the team. In modern distributed teams, "on-site" might mean "on Slack" or "in the daily standup." The key is availability, not physical location.

Without a customer, planning fails. Developers guess at priority. Scope creeps because no one decides what's out. The team builds the wrong thing.