Iteration Planning Meetings (IPM)

Sample Agenda & Prompts

1. Start by framing the conversation for the meeting. Help to set overall project context as needed by briefly recapping recently accepted and in-progress stories or the current state of the newest capabilities in your acceptance environment, to get everyone aligned on where things currently stand as you enter this next iteration. Review the arc of new user stories by outlining what they will add to the product. Present user interface mockups, if available.

2. Read through the first user story to explain the business value, the user value, and the acceptance criteria. Allow participants to ask questions, providing clarifications as needed.

   Tip: Allow space for all members of the team to get the clarifications they need to provide an estimate they feel comfortable with. Beware of individual personalities taking over the conversation or dictating approaches that prevent full team understanding.

3. Prompt the engineers to indicate if they are ready to estimate the user story and if so, to estimate the relative complexity of the story by simultaneously voting on a story point estimate.

   Please see the short guide to estimation below for estimation tips.

4. If there is a consensus on the estimation, label the user story with the estimation result and promote it to the backlog, indicating to the team the priority of this story. Otherwise, if there is no consensus, prompt the engineers to discuss, and re-estimate if necessary until there is a consensus that the team is happy with.

   Tip 1: Try to prevent the conversation from taking too long or veering too far from the scope of this user story. If there is a large amount of uncertainty or disagreement on the scope of this story, it may be necessary to add a chore to the product backlog for investigating or experimenting before this story can be reasonably estimated in a future IPM.

   Tip 2: User stories should remain implementation-agnostic. While some discussion on implementation will naturally arise when estimating relative complexity, try and keep these discussions high-level and park any deep dives on implementation.

5. Repeat steps 2-4 for the remaining user stories that were prepared for this meeting.

   Tip: Use the time available to discuss and estimate as many user stories as were prepared. If necessary, some user stories may be deferred to the next Iteration Planning Meeting. Avoid taking more time than planned, sapping valuable energy from the team

6. In the final 10 minutes of the meeting, review and discuss the relative priorities of product backlog items, including any engineering chores.

   Tip: Prompt the engineers to advise on the scope and importance of chores they wish to promote to the product backlog.

Success/Expected Outcomes

Firstly, the team should have a shared understanding of the scope and relative complexity of the product backlog items that were discussed. Secondly, items should have been added to the product backlog, which remains sorted according to current priorities. The team should come away from IPM feeling aligned and energized about the work coming up in the next iteration.

Facilitator Notes & Tips

• To make IPMs run more efficiently, try to ensure the user stories to be discussed in the meeting have been suitably groomed beforehand. Collaborate with a designer and an engineer to ensure the stories are actionable and meet the INVEST criteria. Avoid trying to hurriedly write stories during the meeting.
• Encourage engineers to create necessary chores and if necessary, work with the engineers to prioritize and groom those chores before the IPM.
• Only hold an IPM if you have already prepared user stories to be discussed and estimated, and your product backlog contains less than 3 iterations of work, according to average team velocity. If you estimate too far out, then estimates may be less accurate and the team may forget the context by the time they begin work on those user stories.

A Short Guide to Estimation

• If there are user stories in the product backlog that were estimated more than 3 iterations ago, consider spending time scheduled for the IPM to review and re-estimate upcoming user stories, if the team agrees it would be helpful.
• Complexity can be estimated relative to other user stories in the product backlog, or relative to a baseline user story.
• Relative complexity is an easier and more reliable way to estimate the size of a user story than the time it may take to complete the work.
• Estimates are typically quantified using “story points”, and the team should align beforehand on the point scale they will use throughout the project, for consistency (e.g. Fibonacci, linear, exponential).
• It’s important that the estimation be done simultaneously in order to avoid bias. A good way to do this is to have participants vote on the count of 3.
• Large story point estimates may suggest the user story should be broken down if the resulting smaller stories can still be valuable to users.
• User stories may be estimated to have 0 story points when there is little or no work to be done beyond acceptance testing/verification.
• It’s OK for story point estimations to be imprecise. The same team working on the same product generally makes more accurate and consistent estimates over time as discrepancies average out.
• Estimation should typically be done only by engineers, or those who will be delivering the work. Other roles, such as Testers and Architects, may contribute when they have a sufficient understanding of the relative complexity.

Related Practices

Sprint Planning vs. Iteration Planning

Scrum “Sprints” and “Iterations” are both timeboxed activities but with some differences that impact how planning is done:

Preceding

Iteration pre-planning (optional)

Recommended Reading

Agile Estimating and Planning by Mike Cohn

Yesterday’s Weather

Planning Poker

Chapter 12 of Extreme Programming Explained by Kent Beck, Cynthia Andres

ExtremeProgramming.org