Stay committed to your decisions but stay flexible in your approach.

—Tony Robbins

Iteration Planning

Note: For more on SAFe Scrum, please read the additional Framework articles in the Scrum series, including SAFe Scrum, SAFe Scrum Master/Team Coach, Iterations, Iteration Goals, Iteration Review, and Iteration Retrospective

Definition: Iteration planning is a SAFe Scrum event where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming Iteration. The team summarizes this work as a set of committed iteration goals.

Details

Iteration planning is the first event of the Iteration. During planning, the team defines, organizes, and commits to the work for the next iteration. The iteration planning meeting is timeboxed to approximately 90 minutes for a two-week iteration. The team’s backlog has been partially identified and planned during PI Planning. In addition, the teams have feedback—not only from their prior iterations but also from the System Demo, stakeholders, and others. All this context feeds into the iteration planning event to inform the plan for the upcoming iteration.

Inputs and Outputs of Iteration Planning

Inputs to iteration planning include:

  • A refined Team Backlog, including Stories from the team’s PI plan, which were identified during PI Planning and tentatively assigned to iterations, new stories that have been identified, and other items from the team’s local context, including defects, refactors, maintenance, and technical debt
  • The Team and ART PI Objectives created during PI planning
  • Feedback from the System Demos and prior iterations, including any stories that did not meet the definition of done (DoD)

A successful iteration planning event delivers the following outputs:

  • Stories planned for the upcoming iteration, including Enablers. Each has defined acceptance criteria and an estimate and is recorded in the iteration backlog.
  • Committed iteration goals.
  • Dependencies with other teams are understood and planned.

Preparation

The teams prepare for the event as follows:

  • Backlog refinement. Teams usually approach iteration planning with a pre-elaborated team backlog from the backlog refinement sessions held during the previous iteration.
  • Close out the previous iteration. The team confirms the stories in the last iteration were completed and accepted. If any remain, they are moved to the team backlog and reprioritized.
  • Initial iteration goals. The Product Owner (PO) may prepare some initial iteration goals based on the team’s progress in the PI.

Process

The PO typically starts the event by presenting high-priority stories from the team backlog and the initial iteration goals (if applicable). Many of these stories originated from PI planning, while others are from the team’s local context. The acceptance criteria are then elaborated through conversation and collaboration with the Product Owner and other stakeholders. Next, they estimate the effort to complete each item using relative story points. Based on the estimates and business value, the Product Owner may change the ordering of the stories.

During planning, the team discusses implementation options, technical issues, Nonfunctional Requirements (NFRs), and dependencies. Next, the PO and team select the candidate stories based on their available capacity for the iteration. Some teams decompose stories into tasks (optional) and forecast them in hours to confirm they have the capacity and skills to complete them. Once planning is complete, the team synthesizes the work into iteration goals, commits to the plan, and records the iteration backlog in a visible place, such as a story or Kanban board and Agile project management tooling.

Attendees

Attendees of the iteration planning event include:

  • The Product Owner
  • Scrum Master/Team Coach
  • All team members and any subject matter experts, as needed
  • Any other stakeholders required, including representatives from other Agile Teams or trains

Scrum Masters/Team Coaches or POs typically facilitate iteration planning for the team, ensuring the participants stay within the agreed agenda and event timebox.

Agenda

An example agenda for iteration planning follows (Figure 1), including a description of each item.

Figure 1. Example iteration planning agenda
Figure 1. Example iteration planning agenda

During planning, the PO defines the ‘what,’ the team determines the ‘how,’ and ‘how much,’ as follows:

  1. Establish capacity – The team calculates its capacity for the upcoming iteration using adjusted historical velocity.
  2. Story analysis and estimation – In conversation with the PO, the team selects and estimates the most valuable stories to meet their PI Objectives, addressing local concerns and dependencies, where applicable.
  3. Tasking stories (optional) – Some teams task stories to understand their capacity and capabilities better. They determine the best person to accomplish the work, estimate the effort (typically in hours), and identify dependencies with other tasks or stories. Planning stops once the team runs out of capacity.
  4. Develop iteration Goals – This process repeats until when the team is out of capacity. Next, the teams summarize the plan as a set of iteration goals. (Note: Some teams work the other way around; they start with iteration goals and then work on capacity, story analysis, and estimating to support those goals.)
  5. Commit to iteration goals – At the end of planning, the Product Owner and team agree on the final list of stories that will be selected, and they revisit and restate the iteration goals. Everyone commits to the iteration goals, and the scope of the work remains largely fixed for the duration of the iteration.

Commitment to Iteration Goals

Iteration goals provide clarity, commitment, and information. The commitment to the iteration goals is reciprocal (Figure 2) and serves the following purposes:

  • Aligns team members to a set of shared objectives for the iteration
  • Focuses teams on meeting their PI objectives and managing dependencies with other teams
  • Provides transparency and management information as needed
Figure 2. Guidelines for team commitments
Figure 2. Guidelines for team commitments

Estimating Stories and Forecasting Team Capacity

Relative Estimation of Stories for Planning

Agile Teams use story points to estimate stories relative to each other [2, 3]. The size (effort) for each item is compared to other stories. For example, an eight-point story should be four times the effort of a two-point story. (Note: Refer to the Story article to learn how to write and estimate stories, including practices for whole team estimation and how to split large stories so they can be completed within an iteration.)

Forecasting Team Capacity

The team forecasts its capacity for an upcoming iteration by using its historical velocity as a starting point. The team’s average velocity (completed story points per iteration) becomes more reliable and predictable as they work together. Predictable velocity helps with planning and limits Work in Process (WIP).

Starting Capacity for New Teams

When the team is new and the average velocity is unknown, one method for initially forecasting the team’s capacity is as follows:

  1. Give the team 8 points for every full-time developer (including test, etc)
  2. Subtract one point for every team member’s vacation day, holiday, or other non-working days in the iteration.

Figure 3 provides an example of forecasting capacity for a new seven-person team.

Figure 3. Example starting capacity for a new team
Figure 3. Example starting capacity for a new team

Creating a Shared Basis for Story Point Estimation

Story points can be aligned (approximately normalized) by teams in the ART, providing a shared basis for capacity forecasting and economic decision-making.

One approach is as follows:

  1. Each team finds a small story that would take a day to develop, test, and validate. Call it a ‘one.’
  2. Estimate every other story relative to that ‘one.’

Moreover, aligning story points enables reasonable estimate costs for features and epics requiring multiple teams’ support. While many teams will increase their velocity over time—and that’s a good thing— in reality, the number tends to remain stable.

 

Learn More

[1] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[3] Cohn, Mike. Agile Estimating and Planning. Robert C. Martin Series. Prentice-Hall, 2005.

 

Last Update: 14 March 2023