Who Can Modify the Backlog During an Iteration

“Stay committed to your decisions but stay flexible in your approach.”
—Tony Robbins

Note: To learn more about SAFe Scrum, please refer to the additional Framework articles in the Scrum series, including SAFe Scrum, SAFe Scrum Master/Team Coach, Iterations, Iteration Goals, Iteration Review, and Iteration Retrospective.

Introduction

Iteration planning is a crucial event in SAFe Scrum that allows team members to determine the amount of work they can deliver during an upcoming iteration. It involves summarizing the work as a set of committed iteration goals.

During iteration planning, the team defines, organizes, and commits to the work for the next iteration. This time-boxed meeting, which typically lasts around 90 minutes for a two-week iteration, builds upon the partially identified and planned team backlog from PI Planning. The team takes into account feedback from prior iterations, the System Demo, stakeholders, and other relevant sources to inform their plan for the upcoming iteration.

Inputs and Outputs of Iteration Planning

Inputs

• Refined Team Backlog, including Stories from the team’s PI plan, new stories, and other items from the team’s local context (defects, refactors, maintenance, technical debt)
• Team and ART PI Objectives created during PI planning
• Feedback from System Demos and prior iterations, including stories that didn’t meet the definition of done (DoD)

Outputs

• Stories planned for the upcoming iteration, including Enablers, with defined acceptance criteria and estimates recorded in the iteration backlog
• Committed iteration goals
• Understanding and planning of dependencies with other teams

Preparation

To prepare for the iteration planning event, teams engage in the following activities:

• Backlog refinement: Teams approach iteration planning with a pre-elaborated team backlog from previous refinement sessions.
• Close out the previous iteration: The team confirms the completion and acceptance of stories from the last iteration. Any remaining stories are moved to the team backlog for reprioritization.
• Initial iteration goals: The Product Owner (PO) may prepare initial iteration goals based on the team’s progress in the PI.

Process

During iteration planning, the Product Owner typically presents high-priority stories from the team backlog and initial iteration goals (if applicable). These stories come from PI planning and the team’s local context. Acceptance criteria are elaborated through collaboration and discussion with the Product Owner and stakeholders. The team estimates the effort required to complete each item using relative story points. Based on estimates and business value, the Product Owner may adjust the ordering of the stories.

The team engages in discussions about implementation options, technical issues, Nonfunctional Requirements (NFRs), and dependencies. They select candidate stories based on available capacity and skills. In some cases, teams decompose stories into tasks to better understand their capacity and capabilities. Tasks are estimated in hours, and dependencies with other tasks or stories are identified. Planning continues until the team exhausts its capacity.

Once planning is complete, the team consolidates 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

The iteration planning event involves the following attendees:

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

Scrum Masters/Team Coaches or Product Owners usually facilitate the iteration planning for the team, ensuring that participants adhere to the agreed agenda and timebox.

Agenda

An example agenda for iteration planning includes the following items:

During planning, the Product Owner defines the “what,” while the team determines the “how” and “how much” as follows:

1. Establish capacity: The team calculates its capacity for the upcoming iteration based on adjusted historical velocity.
2. Story analysis and estimation: In collaboration with the Product Owner, the team selects and estimates valuable stories to meet their PI Objectives. They address local concerns and dependencies where applicable.
3. Tasking stories (optional): Some teams break stories into tasks to gain a better understanding of capacity and capabilities. They estimate the effort in hours and identify dependencies with other tasks or stories. Planning ceases when the team reaches its capacity.
4. Develop iteration goals: This process repeats until the team exhausts its capacity. The teams then summarize the plan into a set of iteration goals. (Note: Some teams follow the reverse order, starting with iteration goals and then determining capacity, story analysis, and estimation 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 selected stories and revisit and restate the iteration goals. Everyone commits to the iteration goals, and the scope of work remains mostly fixed for the duration of the iteration.

Commitment to Iteration Goals

Iteration goals play a vital role in providing clarity, commitment, and information. Their commitment is reciprocal and serves the following purposes:

• Aligning team members to shared objectives for the iteration
• Focusing teams on meeting their PI objectives and managing dependencies with other teams
• Providing transparency and necessary management information

Estimating Stories and Forecasting Team Capacity

Relative Estimation of Stories for Planning

Agile Teams employ story points to estimate stories relative to each other. Story points represent the effort required for each item and are compared with other stories. For example, an eight-point story should be four times more effort than a two-point story. (Refer to the Story article for guidance on writing and estimating stories, including practices for whole team estimation and how to split large stories for completion within an iteration.)

Forecasting Team Capacity

To forecast team capacity for an upcoming iteration, teams rely on their historical velocity as a starting point. As the team works together, their average velocity (completed story points per iteration) becomes more reliable and predictable. A predictable velocity aids in planning and limits Work in Process (WIP).

Starting Capacity for New Teams

In cases where a team is new and lacks an established average velocity, the following method can be used to forecast initial capacity:

1. Assign 8 points for every full-time developer, including testers and other relevant roles.
2. Subtract one point for each team member’s non-working days such as vacation, holidays, or other non-working events during the iteration.

Creating a Shared Basis for Story Point Estimation

Teams within the ART can align story points to provide a shared basis for capacity forecasting and economic decision-making.

One approach is as follows:

1. Each team identifies a small story that can be developed, tested, and validated within a day and designates it as a “one.”
2. Using this “one” as a reference, teams estimate other stories relative to it.

By aligning story points, teams can generate reasonable cost estimates for features and epics that require support from multiple teams. Although teams may improve their velocity over time, the number tends to stabilize.

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