Agile Release & Iteration Planning

What You’ll Learn in this Presentation:

•  The basics of release and iteration planning.
•  The differences between a release and an iteration.
•  The basics of task planning.

Some Things to Remember About Planning…

  • Agile planning is a continual process
    • Development is iterative, and so planning has to respond accordingly.
  • Our planning motto: Work the plan, not work to the plan
    • In other words, “Plans are worthless, but planning is everything.”1  – Dwight D. Eisenhower
    • Planning enables Agile teams to stay focused on business value.

1 From a speech to the National Defense Executive Reserve Conference in Washington, D.C. (November 14, 1957) ; in Public Papers of the Presidents of the United States, Dwight D. Eisenhower, 1957, National Archives and Records Service, Government Printing Office, p. 818 : ISBN 0160588510, 9780160588518.

Agile Planning Horizons


  • Release:
    • 1 to 3 month horizon with defined deliverables, multiple
      iterations, and focus on delivery to the end user.
  • Iteration:
    • 1 to 3 week planning period with multiple user stories,
      greater precision than a release, and focus on delivery
      to the customer / product owner.
  • Task planning:
    • 1 hour team meeting to break a story into more
      manageable tasks, assign tasks to developers, and
      focus on creating a plan to complete a user story.

Who’s Involved In Release Planning?


  • Customers / Product Owners:
    • define stories;
    • set priorities; and
    • put stories into iterations.
  • Developers:
    • estimate stories;
    • point out significant technical risks; and
    • establish velocity, a measure of team development capacity.

Defining a Release Plan


1. Establish iteration lengths

  • Iterations are generally 1 to 3 weeks long.
  • Developers decide what will be in the iteration in collaboration with the customer / product owner.
  • Smaller projects tend to have shorter iterations.
  • Size is important as release dates are usually based on
    external constraints.

2. Determine the velocity

  • Estimate of how many estimating units can be completed per iteration.
  • Developer responsibility.
  • Unit of measurement used does not matter – be it points, ideal days, or something else.

3. Organize stories into iterations

  • Based on business and technical priorities.

Release Plan Variations


A release plan can (and will) be modified in numerous ways:

1. Change priority of stories

  • Stories can be moved from one iteration to the next.
    • Decided by the customer / product owner and happens often.

2. Add new stories

  • Need to determine priority and which iteration the story will fit into.
  • A lower priority story may need to be bumped to make room for new stories of higher priority.


A release plan can (and will) be modified in numerous ways:

3.  Delete stories

  • Has the opposite effect of adding new stories; the gap will need to be filled with other stories previously excluded from the iteration.

4.  Rebuild

  • It’s not unusual at the end of an iteration to review the remaining stories and completely rebuild the plan for the remaining iterations.
  • Remember…work the plan, don’t work to the plan.

Common Release Plan Problems & Solutions

  • Story too large to estimate
    • The story should be split into smaller parts.
  • Story spans iterations due to external dependencies
    • Best to have the developers split the story into two parts:
      1. Finish what can be completed now.
      2. Create second story representing what is not yet done.
  • Story ‘blows up’ due to scope or technical issues
    • The story needs to be halted and re-scoped or re-planned.
  • Release date slides
    • Development team is responsible for reporting this ASAP.
    • Developers and customer / product owner need to work together to de-scope and re-plan.

Example of a Release Plan

Here’s an example of a release that consists of 2 iterations with 12 stories.
  • The release plan is presented 2different ways.

Iteration Planning


Characteristics of iterations to consider when planning:

  • Generally 1 to 3 weeks long.
  • More developer-focused than they are customer /product-owner focused.
  • More precise than releases in terms of their planning focus.
  • Have a specified length of time based on fixed dates.
  • Start by holding an iteration planning meeting.

Iteration Planning Meeting



  • Acknowledge accomplishments of last iteration.
  • Determine the level of overall progress.
  • Review problems and issues.
  • Establish objectives for next iteration.
  • Task planning for target stories (optional).

Estimating Velocity

  • Optimizing velocity is fraught with peril – regardless of the team size, the difficulty level of the work, or the skill level of the team.
    • Predicting the future is unreliable – don’t do it.
    • Velocity is about the team, not individuals.
    • Velocity is a measure of capacity, not performance.
  • Using velocity to compare teams is problematic at best
    • No two projects, domains or teams are the same.
  • Base velocity on “yesterday’s weather”
    • Yesterday’s weather: the velocity for the upcoming iteration is assumed to be the same as that of the previous iteration.

Timing of Task Planning

Two Options:

1. Tasking at the iteration-level

  • Scrum recommends task planning as part of iteration planning, i.e. at the start of an iteration.

2. Tasking at the story-level

  • This can take place as part of iteration planning or separately.
  • At Intelliware, we prefer to task stories when we open them.

Task Planning Meeting

  • Developer-focused meeting to deconstruct a story into a series of finer-grained tasks
    • Customers / product owners can attend, but the meeting content is likely too detailed to be of interest to them.
  • Tasks are recorded in a way that makes them visible
    • Whiteboard or chart paper are typical tools.
  • Tasking makes the story easier to develop
    • Forces the development team to think about implementation issues.
    • Tasks can be worked on by multiple pairs or individuals simultaneously.

Example Task Board

A Task List

  • Task list: the visible list keeps the team focused on tasks.
  • Task meeting process: the task name and size are added during the tasking meeting – the who and when are added later.
  • Designed for pull mode work assignment
    • Pulling tasks encourages the team to work together.
    • Sometimes tasks are assigned to developers or pairs for specific reasons, but this occurs in the context of the team.

Task Attributes

  • Tasks should be quantifiable (in terms of time needed to complete)
  • Tasks are very specific and should have estimates in days, part-days or even hours.
    • Task estimating occurs in the task planning meeting.
  • Tasks should be small
    • No more than a day or two per task.
  • Tasks can be technical
    • Refactoring, system upgrades, etc. are unavoidable.

Task Tracking at Task Planning

Task size estimates provide an early indication of potential issues with the story.

  • Example:
    • Story size estimate: 5 ideal days.
    • Sum of task estimates: 8 ideal days.
  • Over-estimate:
    • 3 ideal days or 160%.
  • Outcome:
    • Team should discuss why task estimate > story estimate.
    • Team should consider ways to develop the story within the original estimate, or split it (and report back to customer / product owner).
  • Tracking during development also provides an early indication of possible issues – don’t leave things festering!

For More Information

For More Information

Mike Cohn’s book, “User Stories Applied” is the definitive reference on release and iteration planning.