Iteration Planning

When planning an iteration, you need to select stories for development, review the requirements, break stories down into development tasks, and then publish the iteration plan.

Some Agile teams prefer to assign stories on the fly during the iteration meeting. If this works for you, then stick with it. I’ve done it this way successfully with teams of up to 3-4 developers. However, with larger teams, I have found that this just doesn’t work all that well. The planning meeting drags on forever, and developer estimates on the fly like that, without taking the time to dive into extended discussion, tend to be far too optimistic. Stories almost always look easy before one thinks through the complications. For larger teams I therefore prefer to prepare in advance.

Choosing stories

There are a few important factors in planning an iteration.

• Customer priority – The top customer priorities should be considered first for inclusion in the iteration work plan.
• Strategic releases – It is important to plan for releases that provide maximum value. Ensure that dependencies (e.g. “this feature only adds value if released together with that feature” or “I can’t do this story until that story is done”) are identified. I find it useful to rough out a plan a milestone in advance to ensure cohesion of the stories to be released. You maintain flexibility, but have a more solid plan for delivering maximum value to the customer as early as possible.
• Bandwidth – You should schedule just enough work based on your team’s bandwidth, i.e. with 3 developers you might have 30 development units (days) for a 2-week iteration. It is also wise to maintain a “bench” of additional stories that can be picked up by developers who finish their work plan early.
• Developer skills – Consider each developer’s personal capacity, areas of expertise, and their career development interests. You may have a high priority story and bandwidth, but sometimes it makes sense to hold off assignment of a story for an iteration or two for a developer who is not immediately available.

Technical review

Once the stories are defined and requirements are complete it is important to have a technical review prior to the start of development. Representatives of Development and QA review the functionality to be built, get their questions answered, and adjust estimates as necessary. This often results in requirements tweaks as well.

Story breakdown

The general rule of thumb for story size is that a story should doable in one iteration. I additionally recommend that developers break down bigger stories into tasks (which I sometimes call "work stories") that take no more than 3 days each. A requirement that I stick to as much as possible is that each work story should be able to be independently delivered and tested. Incremental delivery throughout the iteration enables earlier feedback from the business and QA. Benefits include risk mitigation in the form of earlier course correction as well as a more clear picture of how the team is delivering against the iteration plan.

Publish plan

Publish your plan via project board (read more about Project Boards) so that the team sees it every day, and the customer has easy access. The plan should include the list of assigned stories. For each story, details should include:

• Assigned developer
• Assigned QA engineer (if applicable)
• Story estimate
• Status

This open communication of the plan helps keep everyone on the same page, pushing for the same goal.