A modern priority-based scheduling practice
The Planning Game is one of the core practices of XP. It recognizes the division of responsibilities between business and system developers. The business can say how much a system feature is worth to them, the developers can say how much it will cost to implement. For each release and each iteration within a release, the business is given a budget, and can choose features that add up to, but do not exceed that budget. The budget is based on a velocity that the team has established in preceding work. Early iterations may need to take into consideration the developer priority to establish and test the overall Architecture early (see ArchitecturalSpike). Otherwise, the customers choose priority.
The Planning Game assumes iterative development, and assumes that a team will be able to establish a ‘velocity’ and the ability to estimate effort. Various details of process are required to allow the planning game to proceed effectively such as the ‘right-sizing’ of chunks of functionality to prioritise. Inherent in the Planning Game is a limit to the distance ahead for which detailed planning is done, yet within a suitable environment such as XP, long term planning can be approximated by counting the estimated effort for the remaining pile of features. In case of change of priority, normally the work scheduled for an iteration is not altered, the new priority work will get scheduled for the next iteration.
The customer must be prepared to allocate priority to user stories, much of the value is lost if the customer insists everything is essential and high priority. Having the CustomerOnSite should help, allowing him to spot potential improvements to the plan. Short cycles are highly recommended so that any mistake in the plan can rapidly be detected.