“Stay committed to your decisions, but stay flexible in your approach.”

– Tom Robbins

Iteration Planning Abstract

Iteration planning is one of the mechanisms for decentralizing control and empowering fast local decision making in Lean and Agile development. In basic Scrum, teams plan by selecting items from the product backlog and committing them to the sprint backlog for execution. This basic process is fundamental to SAFe as well, but the context is broader as SAFe teams are “on the Release Train”. As such, the team’s backlog has already been seeded and partially preplanned during the release planning meeting. In addition, the teams have feedback, not only from their prior sprints, but from the System Demo and other teams as well. That, and the natural course of events and changing fact patterns, provides the broader context for iteration planning. However, the planning process is largely the same, as each Agile team plans the upcoming iteration in a timeboxed iteration (or sprint) planning meeting. The output of the meeting is:

The sprint backlog; consisting of the stories committed to the sprint, with acceptance criteria where appropriate
A statement of sprint goals, which are the business objectives of the sprint, typically a sentence or two
A commitment by the team to the work needed to achieve the goal.

The meeting is attended by the Scrum Master, Product Owner, developers and testers and any others who will be involved in the iteration.

Details

Purpose

Iteration planning is one of the prescribed ceremonies (meetings) in Scrum, and therefore occurs in the SAFe Team Level as noted in Figure 1.

Figure 1. SAFe Iteration Planning

The purpose of Iteration Planning is to organize the work and define a realistic scope for the iteration that can be accepted by the team. This Scrum ceremony helps an Agile Team agree on sprint goals, facilitate a reasonable commitment based on the team’s capacity, allowing for consideration of each story’s complexity, size, and dependencies to other stories and other teams.

Inputs to Iteration Planning

In SAFe, Iteration Planning is a refinement of the level of detail and adjustment of the initial sprint plans derived from the PSI/Release Planning session. Teams approach iteration planning with a pre-elaborated Team Backlog, which is typically aided by a separate backlog grooming session prior to the sprint boundary. There are a number of inputs to the planning meeting.

The teams PSI plan backlog, which consists of stories that were planned during release planning
Backlog items based on local context, including things such as defects, refactors, and stories that have come about since the planning session.
Feedback from the prior sprint, including any priority stories that were not successfully completed (did not meet the Definition of Done) in that sprint
Feedback from the System Demo, which will have occurred sometime during the prior sprint
The team’s local and Program PSI Objectives, as established at PSI planning

Overview

Prior to the meeting, the Product Owner will have prepared some preliminary sprint goals, based on the teams progress in the PSI. Typically, the Product Owner starts the meeting by reviewing the proposed sprint goals and the higher priority stories in the team backlog. During the meeting, the Agile team discusses implementation options, technical issues, nonfunctional requirements, and dependencies, and plans the iteration. The Product Owner defines the WHAT; the team defines the HOW and HOW MUCH.

Throughout the meeting, the team elaborates the acceptance criteria and estimates the effort to complete each story. The team then selects the candidate stories based on the teams velocity. Most teams break each story down into tasks and estimate the tasks in hours to confirm they have the capacity and skills to complete the story. Once confirmed, the team commits to the work and records the sprint backlog in a visible place such as a story Kanban board or tooling. The meeting is time boxed to four hours or less.

Ceremony Details

Establish Velocity

First, the team quantifies their capacity to perform work in the upcoming sprint. Each team member determines their availability, acknowledging time off and other potential duties. This activity also takes into account other standing commitments (see “capacity allocation” in Team Backlog) – such as maintenance – that are distinct from new story development.

Sprint Goals

Once team member capacity has been established, the team turns their attention to understanding and agreeing on one or more Sprint Goals that are based on the team and Program Objectives from the PSI/release planning session. The closer this sprint is to the PSI/Release planning session, the more likely the goals will remain unchanged. However, as time elapses and entropy sets in, there is a good chance that the original sprint goals will need some adjustments based on new discoveries. Figure 2 illustrates an example of sprint goals for a particular project:

Figure 2. Sprint Goals Example

Story Understanding and Estimating

With the proposed sprint goals acting as a reference point, the pre-groomed team backlog is reviewed. Each story is discussed by the team, including relative difficulty, size, complexity, technical challenges, and acceptance criteria. Finally, the teams agrees to a size estimate for the story. There are typically other types of stories on a team backlog as well, including infrastructure work, refactoring, research Spikes, architectural improvements, and defects. These are also prioritized and estimated.

Tasks

Most team’s then break each story into Tasks. As the tasks are identified, team members discuss who would be the best person(s) to accomplish each task, approximately how long that task will take (in hours), and any dependencies the task may have on other tasks or stories. Once understood, a team member takes responsibility for the task. As team members commit to tasks, they reduce their individual sprint capacity until their remaining capacity reaches zero. Often, toward the end of the session, some team members will find themselves overcommitted, and others will have some of their capacity still available. This situation leads to further discussion between team members to more evenly distribute the work.

Commitment

When the team’s collective capacity has been reached in terms of committed stories (and tasks), 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 have been moved into the sprint backlog, revisit and restate the sprint goals. The entire team then commits to the sprint, and the scope of the work remains fixed for the duration of the iteration.

Attendees

Attendees of the Iteration Planning meeting include:

Product Owner
Scrum Master (also acts as facilitator)
Developers and Testers, and any other team members who will be involved in the iteration, including QA, documenters, business analysts, tech leads, and architects
Any other stakeholders, including representatives from other agile teams or the program, and business subject matter experts

Agenda

A sample iteration planning meeting agenda follows:

The team determines the velocity available for the sprint
The product owner presents the sprint goals; the team discusses and agrees on the goals
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 if necessary
- Elaborates acceptance criteria through conversation
- Based on size and value/time/risk, the PO may re-rank stories
- In ranked order, the team breaks stories into tasks (estimated in hours) and takes responsibility
- Planning stops once the team runs out of hours
- The team and PO negotiate and finalize the stories selected
- Everyone commits to the sprint goals.

Guidelines

Below are some tips for holding a successful iteration planning meeting:

Timebox the meeting to 4 hours
This meeting is held by and for the team
Never commit to work in excess of the team’s adjusted capacity or historical velocity

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011. Chapter 9

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. Chapter 10

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

Last modified 23 March, 2013