Stay committed to your decisions, but stay flexible in your approach.
—Tom Robbins
Iteration Planning is an event in which 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.
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 will have been seeded and partially planned during the Program Increment (PI) Planning meeting. In addition, the teams have feedback available—not only from their prior iterations, but also from the System Demo and other teams. That information, and the natural course of changing fact patterns, provides the broader context for iteration planning. Iteration planning produces three outputs:
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 by creating 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 team commits to the goal of the iteration and adjusts 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 its goals.
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 (ART) PI planning. Teams approach iteration planning with a pre-elaborated team backlog. (They have usually held a backlog refinement meeting during the previous iteration.) The planning meeting has a number of inputs:
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 the local context, including items such as defects, refactors, and new stories that have emerged 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 chapter) in that iteration
Feedback from the system demo
Prior to the meeting, the Product Owner (PO) will have prepared some preliminary iteration goals based on the team’s progress in the program increment. 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 and then plans the iteration. The Product Owner defines the what; the team members define how and how much.
Throughout the meeting, the team elaborates the acceptance criteria and estimates the effort needed to complete each story. Based on the estimated velocity, the team selects the candidate stories. Some teams choose to break each story down into tasks and estimate the effort needed to complete those tasks in hours to confirm that they have the capacity and skills to meet the iteration goal. The team then commits to the work and records the iteration backlog in a visible place, such as a storyboard, Kanban board, or tooling. Planning is timeboxed to a maximum of four hours for a two-week iteration.
First, the team quantifies its capacity to perform work in the upcoming iteration. Each team member determines his or her availability, acknowledging time off and other potential duties. This activity also takes into account other standing commitments—such as maintenance—that are distinct from new story development (see the section about capacity allocation in the Team Backlog chapter).
Once team member capacity has been established, the team backlog is reviewed. Each story is discussed, including its relative difficulty, size, complexity, technical challenges, and acceptance criteria. Finally, the team agrees to a size estimate for the story. The team backlog typically includes other types of stories as well, such as Enablers that could constitute infrastructure work, refactoring, research Spikes, architectural improvements, and defects. These items are also prioritized and estimated.
Some teams break each story into tasks. As the tasks are identified, team members discuss the relevant details: who will be the best person(s) to accomplish the task, approximately how long it will take (typically in hours), and any dependencies it may have on other tasks or stories. Once all of these details are well 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 a further discussion among team members to evenly distribute the work.
While breaking stories into tasks is fairly common, it is optional and not mandated in SAFe. This approach is mostly used by beginner teams to learn their velocity and capabilities. With greater experience, it becomes unnecessary, such that team planning relies on only stories.
Once the iteration backlog is understood, the team turns its 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 are to 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 selected, 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.
The iteration planning meeting is attended by the following individuals:
The Product Owner
The Scrum Master, who acts as facilitator for this meeting
The Development Team
Any other stakeholders, including representatives from different Agile teams or the ART, and subject-matter experts
An example agenda for iteration planning follows:
Calculate the available team capacity for the iteration
Discuss each story, elaborate acceptance criteria, and provide estimates using story points
Planning stops once the team runs out of capacity
Determine and agree on the iteration goals
Everyone commits to the goals
Acceptance criteria are developed through conversation and collaboration with the Product Owner and other stakeholders. Based on the story estimates, the Product Owner may change the ranking of the stories. Optionally, the team may break stories into tasks, estimated in hours, and take shared responsibility for those tasks’ execution.
Tips for holding an iteration planning meeting follow:
Timebox the meeting to four hours or less
This planning session is organized by the team and is for the team
A team should avoid committing to work that exceeds its historical velocity
Agile teams use story points to relatively estimate the scope of the various user stories [2, 3]. With relative estimating, the size (effort) for each backlog item is compared to other stories. For example, an 8-point story takes four times as much effort as a 2-point story. The team’s velocity for an iteration is equal to the total points for all the stories completed in the prior iteration. Knowing a team’s velocity assists with planning and helps limit Work in Process (WIP)—teams don’t take on more stories than their prior velocity would allow. Velocity is likewise used to estimate how long it takes to deliver Features or Epics, which are also forecasted in story points.
In Scrum, each team’s story point estimation (and the resultant velocity) is typically a local and independent matter. The fact that these estimates might vary significantly—a small team might estimate in such a way that its velocity is 50, while a larger team estimates that its velocity is 13—usually does not pose a concern.
In contrast, in SAFe, story point estimation must be normalized, so that estimates for features or epics that require the support of multiple teams are based on the same story point definition, allowing a shared basis for economic decision-making. One starting algorithm is as follows:
Normalize story point estimation
Find a small story that would take about a half-day to develop and a half-day to test and validate, and call it a ‘1’
Estimate every other story relative to that ‘1’
Establish velocity before historical data exists
For every full-time developer and tester on the team, give the team 8 points (adjust for part-timers)
Subtract ‘1’ point for every team member vacation day and holiday in the iteration
Example: Assuming a six-person team composed of three developers, two testers, and one PO, with no vacations, the estimated initial velocity equals 5 × 8 points or 40 points per iteration. (Note: The team may need to lower this estimate a bit if one of the developers and testers is also the Scrum Master.)
Normalized estimation 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. There is no need to recalibrate team estimating or velocities after that point; this baseline is just used as a common starting point. In this way, all teams estimate the size of work in a common fashion, so management can quickly estimate the cost for a story point for teams in a specific region. Managers then have a meaningful way to establish the aggregate cost estimate for an upcoming feature or epic.
Teams tend to increase their velocity over time—and that is a good thing. Nevertheless, this velocity usually remains fairly stable, and is far more affected by changing team size, makeup, and technical context than by productivity changes. If necessary, financial planners can adjust the cost per story point a bit to account for these changes. 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
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[3] Cohn, Mike. Agile Estimating and Planning. Robert C. Martin Series. Prentice Hall, 2005.