Stay committed to your decisions, but stay flexible in your approach.
Iteration Planning is an event where all team members determine how much of the team backlog they can commit to delivering during an upcoming iteration. The team summarizes the work as a set of committed iteration goals.
Teams plan by selecting Stories from the Team backlog and committing to execute a set of them in the upcoming Iteration. The team’s backlog has been seeded and partially planned during the PI Planning meeting. In addition, the teams have feedback—not only from their prior iterations, but from the System Demo and other teams as well. That, and the natural course of changing fact patterns, provides the broader context for iteration planning. The output of iteration planning is:
- The iteration backlog, consisting of the stories committed to the iteration, with acceptance criteria where appropriate
- A statement of Iteration Goals, typically a sentence or two stating the business objectives of the iteration
- A commitment by the team to the work needed to achieve the goals
The purpose of Iteration Planning is to organize the work and define a realistic scope for the Iteration. Each Agile Team agrees on a set of Stories for the upcoming iteration (the iteration backlog) and summarizes those stories into a set of Iteration Goals. The iteration backlog and goals are based on the team’s capacity and allow for consideration of each story’s complexity, size, and dependencies on other stories and other teams. At the end of planning, the teams commit to the goal of the iteration and adjust stories as necessary to achieve the larger purpose. In return, management does not interfere or adjust the scope of the iteration, allowing the team to stay focused on the goals.
Inputs to Iteration Planning
In SAFe, iteration planning is a refinement of the level of detail and an adjustment of the initial iteration plans created during Agile Release Train PI Planning. Teams approach iteration planning with a pre-elaborated Team Backlog (they have usually held a backlog refinement meeting during the previous iteration). There are a number of inputs to the planning meeting:
- The Team and Program PI Objectives, created at PI planning
- The team’s PI plan backlog, which consists of stories that were identified during PI planning
- Additional stories that arise based on local context, including items such as defects, Refactors, and new stories that have come about since the planning session
- Feedback from the prior iteration, including any stories that were not successfully completed (did not meet the Definition of Done; see “A Scaled Definition of Done” in the Release on Demand article) in that iteration
- Feedback from the System Demo
Planning the Iteration
Prior to the meeting, the Product Owner will have prepared some preliminary iteration goals, based on the team’s progress in the Program Increment (PI). Typically, the Product Owner starts the meeting by reviewing the proposed iteration goals and the higher-priority stories in the team backlog. During the meeting, the Agile Team discusses implementation options, technical issues, Nonfunctional Requirements (NFRs), and dependencies, then plans the iteration. The Product Owner defines the what; the team defines how and how much.
Throughout the meeting, the team elaborates the acceptance criteria and estimates the effort to complete each story. Based on their velocity, the team then selects the candidate stories. Many teams break each story down into tasks and estimate them in hours to confirm that they have the capacity and skills to complete them. Once confirmed, the team commits to the work and records the iteration backlog in a visible place, such as a storyboard or tooling. This meeting is timeboxed to a maximum of four hours.
First, the team quantifies their capacity to perform work in the upcoming iteration. Each team member determines their availability, acknowledging time off and other potential duties. This activity also takes into account other standing commitments (see the “capacity allocation” section in Team Backlog)—such as maintenance—that are distinct from new story development.
Story Analysis and Estimating
Once team member capacity has been established, the team backlog is reviewed. Each story is discussed, covering relative difficulty, size, complexity, technical challenges, and acceptance criteria. Finally, the team agrees to a size estimate for the story. There are typically other types of stories on the team backlog as well, including Enablers that could constitute infrastructure work, refactoring, research Spikes, architectural improvements, and defects. These are also prioritized and estimated.
Many teams then break each story into tasks. As the tasks are identified, team members discuss each one: who would be the best person(s) to accomplish it, approximately how long it will take (typically in hours), and any dependencies it may have on other tasks or stories. Once all this is understood, a team member takes responsibility for a specific task or tasks. As team members commit to tasks, they reduce their individual iteration capacity until it reaches zero. Often, toward the end of the session, some team members will find themselves overcommitted, while others will have some of their capacity still available. This situation leads to further discussion among team members to more evenly distribute the work.
While breaking stories to tasks are is a common, it is optional and not mandated in SAFe. It is mostly used by beginner teams to learn their velocity and capabilities, and then they become unnecessary, with the team planning simply with stories.
Once the iteration backlog is understood, the team turns their attention to synthesizing one or more iteration goals that are based on the team and program PI objectives from the PI planning session and the iteration backlog. The closer this iteration is to the PI planning session, the more likely the program objectives will remain unchanged.
When the team’s collective capacity has been reached in terms of committed stories, no more stories are pulled from the team backlog. At this point, the product owner and team agree on the final list of stories that will be achieved, and they revisit and restate the iteration goals. The entire team then commits to the iteration goals, and the scope of the work remains fixed for the duration of the iteration.
Attendees of the iteration planning meeting include:
- The Product Owner
- The Scrum Master, who acts as facilitator for this meeting
- The Development Team
- Any other stakeholders, including representatives from other Agile Teams or the ART, and subject matter experts
A sample iteration planning meeting agenda follows:
- The team determines the velocity available for the iteration
- The team discusses each story in ranked (sequenced or prioritized) order. For each story, the team:
- Sizes/resizes each story in story points and splits them if necessary
- Elaborates acceptance criteria through conversation
- Based on size and value/time/risk, the PO may re-rank stories
- Optional: In ranked order, the team breaks stories into tasks, estimated in hours, and takes responsibility
- Planning stops once the team runs out of points
- The team discusses and agrees on the goals
- Everyone commits to the iteration goals
Below are some tips for holding a successful iteration planning meeting:
- Timebox the meeting to 4 hours or less
- This meeting is held by and for the team
- A team should never commit to work in excess of its adjusted capacity or historical velocity
Relative Estimating, Velocity, and Normalizing Story Point Estimating
Agile Teams use relative estimating [2, 3] to estimate the size of a story in story points. With relative estimating, the size (effort) for each story is estimated relative to the size of other stories. The team’s velocity for an iteration is equal to the sum of the size of all the stories completed in the iteration. Knowing a team’s velocity assists with planning and is a key factor in limiting WIP, as teams simply don’t take on more stories than their prior velocity would allow. Velocity is also used to estimate how long it takes to deliver larger Features or Epics, which are likewise estimated in story points.
Normalizing Story Point Estimating
In standard Scrum, each team’s story point estimating—and the resultant velocity—is a local and independent matter. The fact that a small team might estimate in such a way that they have a velocity of 50, while a larger team estimates so as to have a velocity of 12, is of no concern to anyone. In SAFe, however, story point velocity must be normalized to a point, so that estimates for features or epics that require the support of many teams are based on rational economics. After all, there is no way to determine the return on potential investment if you don’t know what the investment is.
In order to do this, SAFe teams start down a path where a story point for one team means about the same as a story point for another. In this way, with adjustments for economics of location (the U.S., Europe, India, China, etc.), work can be estimated and prioritized based on economics by converting story points to cost. This is particularly helpful in initial PI planning, as many teams will be new to Agile and will need a way to estimate the scope of work in their first PI. One starting algorithm is as follows:
- For every individual contributor on the team, excluding the Product Owner, give the team eight points (adjust for part-timers).
- Subtract one point for every team member vacation day and holiday.
- Find a small story that would take about a half-day to develop and a half-day to test and validate. Call it a 1.
- Estimate every other story relative to that one.
Example: Assuming a 6-person team composed of 3 developers, 2 testers, and 1 PO, with no vacations, etc., then the estimated initial velocity = 5 * 8 points = 40 points per iteration. (Note: The team may need to adjust a bit lower if one of the developers and testers is also the Scrum Master.)
In this way, all teams estimate the size of work in a common fashion, so management can thereby fairly quickly estimate the cost for a story point for teams in a specific region. They then have a meaningful way to establish the aggregate cost estimate for an upcoming feature or epic.
Note: There is no need to recalibrate team estimating or velocities after that point. It is just a common starting point.
While teams will tend to increase their velocity over time—and that is a good thing—in fact, the number tends to remain fairly stable, and a team’s velocity is far more affected by changing team size, makeup, and technical context than by productivity changes. And, if necessary, financial planners can adjust the cost per story point a bit. This is a minor concern compared to the wildly differing velocities that teams of comparable size may have in the non-normalized case.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007,.  Cohn, Mike. Agile Estimating and Planning. Robert C. Martin Series. Prentice Hall, 2005.
Last updated: 21 June, 2017