Iteration planning

Iteration planning2018-09-11T14:06:49+00:00

IterationPlanningWorkflow

 

Context

Summary

Provide a summary of this practice.

Iteration Planning defines, assigns and schedules the development of User Stories for a single iteration.

For general principles of Agile planning, click here.

Purpose

What is the overall goal or intention of this practice?

Iteration planning is used:

  1. to identify and evaluate the features, stories and other backlog items the team believe they can complete during the iteration.
  2. to define and allocate the individual tasks needed to complete development, acceptance & final delivery.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

Iteration planning should not generally take more than 2-4 hours. More generally, to set your meeting timebox (in hours), multiply the expected iteration duration (in weeks) by 2.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

  1. The iteration features and stories have been agreed between the team and the Product Owner.
  2. The iteration stories are mature enough for development to begin.

Entry conditions

What pre-conditions must be met before this practice is used?

  1. The basic conditions for successful delivery are in place, typically as a result of work conducted during Iteration 0.
  2. A backlog of well-defined stories and other items (e.g., bugs) is available in the release backlog.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Prepare planning meeting.
  1. Ensure that all preparations and inputs are ready.
    • Release Plan.
    • Release Backlog.
    • Business vision and goals.
    • Provisional Iteration Backlog
    • Preliminary story estimates.
  2. Identify additional participants.
  3. Schedule the meeting.
  4. Package meeting inputs.
  5. Prepare & circulate meeting agenda.
2Initiate planning meeting
  1. Open meeting.
  2. Explain the meeting’s purpose.
  3. Outline the expected outputs and exit conditions.
  4. Agree agenda, meeting schedule, etc.
3Agree iteration goals.
  1. Product Owner walks through the release:
    • Release features.
    • Release themes.
    • Release epics.
    • Release goals.
  2. Product Owner walks through candidate iteration stories, including priorities.
  3. All participants review any goals the team failed to complete in previous iterations.
  4. All participants agree appropriate goals for the current iteration:
    • Specific outcomes related to the selected iteration stories.
    • Quantitative targets or results (e.g., internal deadlines) for the iteration as a whole.
4Finalise iteration stories.For each story:

  1. Check whether it has changed since Release Planning.
  2. If the story seems too big, partition it into more manageable units.
  3. Identify any functional, technical or architectural issues.
  4. Does the team have the skills to implement the story?
  5. Identify dependencies and their impact on development.
  6. Confirm the story’s testability.
  7. If necessary, revise the story’s priority.
  8. Document new or changed stories, as they arise from discussion.
5Translate stories into tasks.
  1. For each story, prepare Task Cards documenting the development tasks needed to complete it.
6Define non-story tasks
  1. Identify & schedule any additional tasks:
    • Required for this specific iteration.
    • Scheduled for this period during Iteration 0.
7Assign tasks.
  1. Team members choose tasks.
  2. Tasks are updated to show assignments.
8Commit to delivery.
  1. Each team member explicitly commits themselves (verbally) to delivering the iteration as now planned.
9Update Iteration Backlog.
  1. Update Iteration Backlog.
10Validate Iteration Plan.
  1. Validate the overall iteration task plan.
  2. If the plan fails any of these tests, the Product Owner should re-prioritize the stories.

Detailed process

#StepByOutputInstructionsNotes
1Prepare planning meeting. 

Iteration Lead.

Product Owner.

Meeting schedule.

Agenda.

Meeting inputs.

  1. Ensure that all preparations and inputs are ready.
    • Release Plan.
    • Release Backlog.
    • Business vision and goals.
    • Provisional Iteration Backlog
    • Preliminary story estimates.
  2. Identify additional participants.
  3. Schedule the meeting.
  4. Package meeting inputs.
  5. Prepare & circulate meeting agenda.
  • Iteration planning meetings should include the Product Owner, the Iteration Lead and the entire iteration team.
  • Other stakeholder should not normally be invited.
2Initiate planning meetingIteration Lead.

Team.

Product Owner.

  1. Open meeting.
  2. Explain the meeting’s purpose.
  3. Outline the expected outputs and exit conditions.
  4. Agree agenda, meeting schedule, etc.
3Agree iteration goals. 

Iteration Lead.

Team.

Product Owner.

Agreed iteration goals.
  1. Product Owner walks through the release:
    • Release features.
    • Release themes.
    • Release epics.
    • Release goals.
  2. Product Owner walks through candidate iteration stories, including priorities.
  3. All participants review any goals the team failed to complete in previous iterations.
  4. All participants agree appropriate goals for the current iteration:
    • Specific outcomes related to the selected iteration stories.
    • Quantitative targets or results (e.g., internal deadlines) for the iteration as a whole.
  • Goals only need to be set if the iteration is seen as difficult or complex, or if achieving previous goals has been unexpectedly hard.
  • A goal should take the form of a single sentence such as ‘Create a job search function, with direct uploading of jobs by agencies and direct employers, and direct submission of candidate applications.’
  • Goals should be easy for outside stakeholders to understand and evaluate.
4Finalise iteration stories. 

Iteration Lead.

Team.

Product Owner.

Updated Iteration Backlog.For each story:

  1. Check whether it has changed since Release Planning.
  2. If the story seems too big, partition it into more manageable units.
  3. Identify any functional, technical or architectural issues.
  4. Does the team have the skills to implement the story?
  5. Identify dependencies and their impact on development.
  6. Confirm the story’s testability.
  7. If necessary, revise the story’s priority.
  8. Document new or changed stories, as they arise from discussion.
  • Large or complex stories (‘epics’) should be split into stories that add value in their own right, and not (for example) into the steps in a process or components of a system that will only work as a whole.
  • Where risky but potentially valuable items are present, these should be prioritized, so the risk is addressed and options and alternatives are considered in good time.
5Translate stories into tasks. 

Iteration Lead.

Team

Task Cards.
  1. For each story, prepare Task Cards documenting the development tasks needed to complete it.
  • Don’t expect to be able to list all the tasks you will eventually need to do. Do as much as you can, but expect the task list to evolve as the iteration unfolds.
  • It may be more practical to divide the stories among the team and have one or two team members draft the Task Cards for each story, which the rest of the team can then review.
  • While user stories are written in the user language, tasks are written in developer language.
  • Tasks should generally be between 1/2 and 2 days in duration. Anything larger should be analysed into further detail.
  • The tasks should include everything in your Definition of Done.
  • The Definition of Done may need to be amended as the nature of the tasks in the iteration reveals new needs.
  • The level of detail should be enough for:
    • progress to be realistically assessed in the Daily Stand-Up Meetings.
    • the impact of changes to be understood.
    • the effort needed to finish the iteration to be estimated.
6Define non-story tasks 

Iteration Lead.

Team.

Updated Task Cards.Identify & schedule any additional tasks:

  1. Required for this specific iteration.
  2. Scheduled for this period during Iteration 0.
Typical non-story tasks include:

  • Training.
    • Given & received.
    • Especially for new team members.
  • On-going foundational stories & tasks.
  • Structured/formal interactions with external groups.
    • Showcases, meetings, Stakeholder liaison & other events.
    • Giving & receiving information & decisions.
  • Managing dependencies.
  • Supporting deployment.
  • Improvement tasks.
  • Retrospective & backlog refinement meetings.
  • Holidays (public & personal).
7Assign tasks.Team.

Iteration Lead.

Updated Task Cards.
  1. Team members choose tasks.
  2. Tasks are updated to show assignments.
  • Team members volunteer to take on tasks by selecting the ones they are happy to do. They are not imposed.
8Commit to delivery.Team.

Iteration Lead.

Team commitment to delivering the iteration.
  1. Each team member explicitly commits themselves (verbally) to delivering the iteration as now planned.
  • If a team member cannot make this commitment, the meeting backtracks to the relevant impediment for further discussion and adjustment.
9Update Iteration Backlog.Team.

Iteration Lead.

Updated Iteration Backlog.
  1. Update Iteration Backlog.
  • Iteration-level estimates should always be preferred to previous estimates (e.g., when the release was estimated).
  • Estimates should be verified against the assigned individual’s previous velocity – is this story too much for them to deliver in the time available?
10Validate Iteration Plan.Iteration Lead.

Product Owner.

Team.

Finalised Iteration Plan.
  1. Validate the overall iteration task plan.
  2. If the plan fails any of the tests suggested in the Notes column, the Product Owner should re-prioritize the stories.
Validate the plan against:

  • The iteration/sprint’s goals.
  • Backlog prioritisation.
  • Your Definition of Done.
  • Known issues with the iteration.
  • Your Release Plan.
  • Your Iteration 0.
  • Duplications.
  • New dependencies.
  • Major development overheads.
  • External events and deadlines, and other unavoidable downtime such as public holidays, personal leave and company events.

Finally, the plan needs to be compared with the team’s historic velocity.

  • Are we really able to do all this in the time available?
  • Could we (sustainably) do more?

Click for more detail on validating plans.

Issues & risks

What are the key concerns in making a success of this practice?

  • Iteration planning is not a one-off event, even within a single iteration. Release stakeholders are entitled to revise stories and their priorities at any point. But if they do, it’s their responsibility to make sure the team know about these changes in good time.
  • The team should also carry out a periodic structured refinement activity.
  • Formal replanning may not be required, but adjustments should be reviewed with the Product Owner.
  • When working out which stories to implement first, try to create a mixture of story sizes, so that a bottleneck is not created and the whole team can be actively engaged as much as possible.
  • The burn rate and velocity chart should be constantly visible to the team and under their regular review, and if major discrepancies arise, the Iteration Plan should be revisited.
  • Whatever changes are made to the Release and Product Backlogs, only the iteration team may authorise changes to the Iteration Backlog.
  • Although they need to be available to provide decisions and detail, it can be difficult for the team to express itself freely if the Product Owner is present throughout the meeting.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?