Friday, October 2, 2015

Iteration Planning

A number of agile practices take the form of regular meetings. We have already seen the "daily meeting", but there are others, codified in particular by Scrum.

At the start of an iteration (a sprint in Scrum) there should be a meeting to plan that iteration. The meeting should produce three main outcomes:

1. An iteration goal, describing what the team plans to achieve in the iteration, concisely — a sentence or two — and in terms understandable by ordinary stakeholders. A typical example (assuming a compiler project) is: implement the new functional-language extensions.

2. An iteration backlog: the list of tasks to be implemented. This outcome is primarily for the internal benefit of the team.

3. The list of acceptance criteria for each task.

Conspicuously absent from these goals are: the assignment of tasks to individual team members, which will be done at the "last possible moment" according to the rule of cross- functionality; and a list of testing tasks, since testing is done continuously as part of the implementation of user stories, not as a separate activity.

The meeting is primarily reserved for the team and the product owner. As the team will be responsible for implementing the backlog in the allotted time, the result represents a commitment on its part, normally ruling out the participation of observers.

The definition of tasks (outcome 2 above) is a two-step process: select user stories from the backlog for the entire product; then, decompose each of them into tasks.

The process also requires estimating the cost of each task. This is where techniques such as the planning game and planning poker, discussed earlier in this chapter, come into play. Because the team is in the best position to size up tasks that it will have to implement, the product owner may at times be asked to leave the meeting while this estimation is in progress. Disagreements may imply repetitive application of the process.

To avoid endless discussions, the meeting has a time limit, generally a single day (eight hours), sometimes split into two parts, one for selecting user stories and the other for decomposing them into tasks.

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

No comments: