Planning game

We play the planning game once a week, usually on Tuesday.

The planning process has two phases: release planning and iteration planning.

Release planning

A “release” is a version of a software system made available to its users with a certain set of features.

We will initially plan for two releases: one at mid-semester, in early March right before spring break, and one at the end of the semester. This gives us approximate 6 weeks per release.

Writing user stories

We first write user stories describing potential features, classifying these stories by value, cost, and risk.

We then decide which stories we want to commit to for the next release.

Making a collective commitment

The number of stories we can commit to depends on the total cost (in labor time) of the stories, and the number of developers we have. For each release, we theoretically have 6 weeks (36 hours) of labor time per developer. So, if we had 10 developers, in theory we could commit to 60 weeks’ worth stories for a release. (In practice, we should probably expect to accomplish only half that, or less.)

The stories we commit to for the next release are then ordered so that:

1. each story comes before the stories that depend on it (if any)
2. more valuable stories come before less valuable ones
3. riskier stories come before less risky ones

When comparing two stories for ordering, each ordering rule is applied only if the previous rule does not result in an ordering: value is considered only if there are no dependencies between the stories, and risk is considered only if their value is the same.

Iteration planning

An “iteration” is 1 week, or 6 hours, of developer time.

Each week, we will

1. evaluate progress on current tasks,
2. adjust our plans if necessary, and
3. add new tasks, if there are any.

Evaluating progress and adjusting plans

This is where we learn

• to distinguish between the amount of labor time we theoretically have, and the amount we actually have, or
• (looked at another way) to make better estimates of how long it will take to complete tasks.

Each week we will have a set of tasks that were estimated to be completed by that week. Each task is either marked as completed, or its cost is re-estimated.

Re-estimating the cost of a task may result in needing to re-estimate the cost of the story to which it corresponds.

If all the tasks of a story have been completed, we can compare estimated and actual project velocity (in stories per week). Based on that velocity, we may decide to reduce the number of stories in the current release.

Creating developer tasks

If every developer has already committed to 6 hours worth of tasks for the upcoming iteration, then iteration planning is finished.

Otherwise, we take the next user story (according to the ordering described above) planned for inclusion in the upcoming release, and translate it into developer tasks.

Making an individual commitment

Then, each individual developer chooses the task(s) they would like to take responsibility for.

They must estimate the cost in hours of labor time that the task will take them. Estimating the cost of tasks may result in needing to re-estimate the costs of the stories to which they correspond.

Each developer should commit to a maximum of 6 hours’ worth of labor each week, taking into consideration what they’ve learned about their personal task velocity. If they estimate that an individual task will take them more than 6 hours, they should break it down into sub-tasks and only commit to the first one(s).