Srum Planning Game

The next two practices to be reviewed (in this section and the next) address one of the toughest challenges of software management and development: estimating the cost of a system to be developed, or part of that system. The planning game comes from Extreme Programming, the planning poker from Scrum. Cost estimation, the goal in both cases, is only a subset of what "planning" normally covers; but this limited scope of the term is consistent with the rest of the agile creed, which does not like the idea of upfront tasks.

The unit of estimation has traditionally been a unit of work: person-month or, at a finer level of granularity, developer-day (one programmer working for one day). More sophisticated metrics have been developed recently, in particular the story point, which we will study in the discussion of artifacts. The discussion in this section and the next does not depend on the particular metric used.

The XP planning game is a "game" not in the sense of a competition, with winners and losers, but in the game theory sense of a cooperative game, where two actors try to maximize different criteria and seek an optimal compromise between them. The two actors are "business" and "development" in Beck's term, or more simply the customer and developer groups. The customers seek to maximize functionality and minimize the time to obtain it. The developers understand the difficulty level associated with every element of functionality, and the incompressible time that it requires. In the game:

- Customers define the respective priority of a set of functionality elements — defined in agile style as user stories — for a project, or a particular iteration.

- Developers estimate the cost (person-days) of implementing each story.

In playing the game, the two groups perform these tasks repeatedly, engaging into negotiation over the estimates. Customers sort the stories on the basis of priority. The game terminates when the two sides have agreed to select the highest-priority tasks with a total cost that fits within the time allotted for the release and the number of developers. In a variant of the game, the result is not so strictly tied to a release cycle but simply consists of a prioritized list of user stories.

Taken from : Agile!: The Good, the Hype and the Ugly