Simplified Iteration Planning

Introduction

XP teams generally use relative story points along with the “Yesterday’s Weather” rule for story planning, but there’s more variety in how they do iteration planning:

• Relative estimates (typically as one to three “task points”)
• Absolute estimates (in days or hours)
• No task estimates (but using a shared sense of when a task is “too big”)

This article describes a simplified approach to iteration planning that omits task estimates.

Planning

1. The team reports the number of story points completed last iteration.
2. The Customer selects that same number of story points for the next iteration. (This is known as the “Yesterday’s Weather” rule.)
3. The Customer prioritizes the selected stories high to low.
4. Find a blank area to for the task list (whiteboard, large piece of paper, …).
5. Working from highest priority story to lowest:
   1. Read the story; write its name and estimate on the task list.
   2. Brainstorm the tasks that will accomplish this story. Keep them short (about half a day for a pair is a good size). It’s preferred that the Customer participate in this brainstorming.
   3. Write down the tasks you decide on underneath the story.
   4. Add a task “Verify story is complete.” (This could include verifying tests, checking off the story, walking through it with the customer, etc.)
   5. Leave some blank space before the next story.
6. Eyeball the tasks to make sure it looks feasible to complete the planned stories. If necessary, adjust a story’s estimate, and get the Customer to drop or split stories to reach the planned number of points.

During the Iteration

• If you have no active task, sign up for the next task.
  • “Next” is any task from the unfinished story that has the highest priority.
  • If the task breakdown makes it hard to do a task on the current story without stepping on somebody else’s feet, it’s acceptable to pick a task from the next most important story; but work on your ability to break down stories into nearly independent tasks.
  • Sign up as individuals rather than pairs. (Some teams do the opposite but I like pairs to feel more fluid.)
• When you complete a task, cross it off and select another one.
• If you need to split a task or if you realize that some other task needs to be included for this story, add it in the spare blank space. Make sure others are aware of what you’ve done.
• Have a set time, about halfway through the iteration, for a “sanity check”: make an assessment of whether you’re on track to finish the stories planned for this iteration. Shuffle around people or tasks as needed to make this happen, or let your Customer know if you expect to need them to split, drop, or add stories.
• Maintain a high level of team communication: shared workspace, pairing, standup meetings, talking to the whole room, asking for help, retrospectives, and so on.

Consequences

• Developers are signed up for only one task at at time.
• The highest priority story is being worked on at any time.
• Relatively small tasks are less likely to be bigger than expected, and may let a team apply more pairs to a story concurrently.
• Stories are completed throughout the iteration (rather than all at once in a “little bang” at the end of the iteration).
• If there’s too much work for the iteration, or if a new story comes in, the lowest priority story probably has had no work done on it.
• An explicit “verify story” task helps make sure the tasks add up to the whole story (and gives an opportunity to make sure the Customer agrees).
• The team’s focus is on story completion.

Comparison to “Classic” Iteration Planning

Iteration planning as described in most of the XP books (including Extreme Programming Explained, Extreme Programming Explored, Planning Extreme Programming, etc.) is a little more “front-loaded” than in the simplified form described above:

• Classic iteration planning has both story points and task points; simplified planning uses story points only.
• Classic iteration planning in Extreme Programming Explained uses task cards and load factor; simplified planning uses text on a chart. (I don’t know of any teams that still use the “white book” approach.)
• Classic iteration planning talks about individual velocities; simplified planning doesn’t address that.
• Classic iteration planning allows for a tracker role, to help figure out whether individuals, tasks, and stories are on track; simplified planning has less need for a tracker.
• Classic iteration planning has no slack to allow for new tasks coming in; simplified planning accepts that new tasks will arrive, so it doesn’t commit people past their current task.
• Classic iteration planning relies on the team’s and the individuals’ ability to balance the load based on their guess at the beginning of the iteration; simplified planning balances the load during the iteration.

The scales aren’t tipped fully one way:

• Simplified planning relies more heavily on communication during the iteration.
• Simplified planning doesn’t give direct feedback on individuals’ velocity.
• Simplified planning prefers smaller tasks.

Conclusion

This article has described a simplified form of iteration planning. By keeping tasks small, maintaining team communication, and focusing on the highest priority story first, iteration planning can become easier and the team can be more responsive.

Resources and Related Articles

• Extreme Programming Explained: Embrace Change, Kent Beck.
• Planning Extreme Programming, by Kent Beck and Martin Fowler.
• “An Iteration Planning Game,” in Extreme Programming Explored, by Bill Wake.

[Written September, 2002. Revised Sept. 8, 2002 in response to Mike Clark’s suggestion.]