Extreme Programming Practice: Planning Game

In Extreme Programming, the planning game is a planning meeting held by the development team and stakeholders. It has two sessions: release planning and iteration planning. Customers and all developers in the team must participate.

The planning game of Extreme Programming is similar to the planning meeting of Scrum. User stories are also adopted in Extreme Programming to manage and track user requirements. In fact, the concept of user stories originated from Extreme Programming.

Both the release planning and the iteration planning of the planning game include three phases, namely exploration, commitment and guidance.

Release Planning

In the phase of exploration, the customer collects user stories and writes them on the user story cards. The developer estimates the required man-hours for each user story and writes the estimated value on the story card. If a user story cannot be estimated, it will be re-decomposed by the customer and then estimated by the developer.

In the phase of commitment, customers prioritize user stories based on business value, and the developers prioritize user stories based on risk, and confirm the development velocity. Finally, the customer chooses the user story to be completed for the next release.

In the phase of guidance, developers and customers can adjust and modify the plan. For example, the priority of user stories can be changed, and the deviations of estimates exist. This is an opportunity to adjust the plan accordingly.

Iteration Planning

The iteration planning is further planning of the release planning, which is done right at the beginning of each iteration. 

In the phase of exploration, the team discusses each user story and breaks it down into tasks, and then estimates the working hours for the tasks.

In the phase of commitment, each developer voluntarily claim tasks and makes a final estimate of the tasks he is responsible for and the team should evaluate whether they are overloaded. One or more developer is responsible for one task.

In the phase of guidance, in each subsequent iteration, developers implement each task through pair programming, c ontinuous integration, test-driven development and other practices, and finally do  functional testing.

Summary

The supporters of Extreme Programming believe that the continuous change of software requirements is inevitable, natural and acceptable in software development projects. They also believe that all requirements should be defined at the beginning of the project. Rather than controlling changes, XP practices support each other, and adapt to changes at any stage of the project cycle, which will be a more effective method. For example, pair programming, code specification, collective code ownership, continuous integration and other practices enable the team to refactor the code easier. 

• Extreme Programming: On-Site Customer