One step at a time is good walking.

- Old Chinese proverb




Iterations Abstract

Virtually all Agile development methods are based on the fundamental construct of an iteration, a strict time-box in which teams deliver incremental value in the form of working, tested software. In SAFe, we assume that the basic team-level agile project management practices are based on Scrum, which is a well defined, nearly ubiquitous, and effective process for Agile at the team level. In addition, as high levels of endemic code quality are necessary to build reliable, large-scale systems, we also focus on Agile technical practices. Many of these were driven largely by Extreme Programming, as well as certain extensions and later developments in the area of Agile architecture, Agile modeling and Acceptance Test-Driven Development.

This basic iteration (Sprint in Scrum; we use that term interchangeably) construct has a standard, repetitive pattern, which we build on in the Scaled Agile Framework. Simply, each Agile Team defines, builds, and tests a valuable increment of software in a common, two-week time box. The sequence is simple: plan the iteration; commit to a set of stories and goals; implement the selected stories; demo the work to the key stakeholders; and, finally, hold a retrospective, whereby the team analyzes and makes the changes necessary to improve its performance. In addition, each iteration is conducted in the context of an Agile Release Train, which aligns multiple teams and sprints to a common mission and cadence, and provides the fast feedback necessary to make mid course adjustments.


In each iteration, the Agile Team commits to deliver a certain scope of business value within a fixed time box via elaboration, coding and testing of a select set of User Stories.  Each Agile team continuously grows both the product and the teams abilities,  iteration after iteration.

Iteration Structure

Iterations have a fixed, two-week length in SAFe.  This is the optimal timeframe to be able to define/build/test enough user stories to provide value to the business while having enough feedback points to adapt to needed change during the PSI/Release. In SAFe, teams iterations start and end dates are synchronized to allow for integration, evaluation and full System Demonstration on (at least) two week boundaries. Figure 1 illustrates the teams iteration/sprint process, in the context of the Agile Release Train.


Figure 1. Illustration of a team’s sprint in SAFe

  • Planning – In planning, the team’s backlog is typically seeded with stories identified to deliver the various Features (and Objectives) that were identified and committed during Release Planning. During Iteration Planning, the team picks as many Stories from the team backlog as they can deliver in the sprint. In addition to the backlog, planning inputs include feedback from the prior iteration, feedback from the system demo and the context provided by the team’s PSI Objectives. Time boxed to four hours or less, the sprint planning meeting has three outputs:
    1) an iteration backlog, which is the set of stories (and associated acceptance criteria for most)
    2) the Sprint Goals, which are a summary statement of the business objectives of the sprint
    3) a commitment form the team to the goals of the sprint
  • Executing – During the iteration, the team takes stories from the iteration backlog and implements them by collaboratively developing and testing the functionality necessary to satisfy the acceptance criteria. Once a story is complete, it is reviewed and demonstrated to the Product Owner who either a) accepts the story into the new baseline, at which point the team then moves to the next priority story, or b)  the team reworks the code and tests as necessary.  Many teams also have a Backlog Refinement meeting (see Team Backlog) in the middle of the iteration. The purpose of this meeting is to refine the backlog by elaborating on user stories scheduled for future iterations.

The sprint ends when the two-week timebox is over, whether all the stories are completed or not! The sprint end has two important activities, the Team Demo and Retro.

  • Team Demo –  The purpose of the Team Demo is to measure the team’s progress by showing working software to the development team, Product Owner and other stakeholders where applicable. This feedback is structured as a 1-2 hour demonstration of new functionality.
  • Retro – The final activity in every sprint is a short  Iteration Retrospective. The purpose of the retro is to reflect on the iteration and derive new ideas to improve the process.  This helps instill kaizen mind in the individuals and the team, and helps assure that every iteration makes some small improvements in the team’s process.
Thereafter, some team members may also participate in a  System Demo, which aggregates the individual sprint achievements into consistent, system level behavior suitable for review by Product Management and other business stakeholders.

Executing and Tracking

Lean practices teach us to limit work in process by fully completing a few stories before moving on to the next set. This evens the flow of work and enables early (in days!) value delivery, while also improving predictability. Team’s also follow Agile Code Quality practices, including things such as continuous integration and test automation, in order to ensure quality and sustainability of the cadence. These practices help assure both flow and velocity.

Teams track iteration status through the following methods and tools:

  • Story board/BVIR – The teams story board or Big Visible Information Radiator (BVIR) provides  progress visibility for the iteration’s backlog items (see Figure 2 below) by visually showing what state each story is in. The story board helps the team easily identify what’s remaining in order to successfully complete the iteration. In addition, the story board can also serve as a reminder for limiting work in process (some teams place WIP limits on each state).
  • Daily stand-up meeting – A short 15-minute meeting – where the team quickly shares information about the previous day’s progress, coordinates activities for the current day, identifies dependencies, and reports impediments – is mandatory.
  • Burn-Down Chart (BDC) – Some teams use a graphical representation, or burn down chart, which shows the amount of work left to do versus time remaining (see Figure 2, to the left of the status board).

Figure 2. Daily stand-up meeting

The primary output of the iteration is tested, working software. It is also  important for the team to not let any unfinished work (such as test automation, synchronization of documents, testing non-functional requirements, etc.) go beyond the iteration boundary. For a number of reasons it may be impossible to do it all at once initially. Thus the team should come up with a realistically achievable Definition of Done (DoD) for the stories in the iteration and then gradually extend the DoD after each iteration until an ideal DoD state is reached to avoid accumulating unfinished work.

Relative Estimating, Velocity and Normalizing Story Point Estimating

Relative Estimating and Velocity

Agile teams use relative estimating and estimating poker [Ref 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 (effort) of the smallest story. The team’s velocity for a sprint is equal to the sum of the size of all the stories completed in the sprint. Knowing a team’s velocity assists with planning, and is a key factor in limiting WIP (teams 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 also 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, concern; the fact that a small team might estimate in such a way that they have a velocity of 50, while a larger team has 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 is based on rational economics. In order to do so, SAFe teams are started down a path where a story point for one team means about the same as a story point for another, so that with adjustments for economics of location, (US, Europe, India, China, etc.), work can be estimated and prioritized based on economics by converting story points to cost.  After all, there is no way to determine the return on potential investment, if you don’t know what the investment is. The algorithm we use for normalizing teams to a common, starting story point and velocity baseline is as follows:

  1. For every developer tester on the team, give the team eight points (adjust for part timers)
  2. Subtract one point for every team member vacation day and holiday
  3. Find a small story that would take a about a half-day to code and a half-day to test and validate. Call it a 1.
  4. Estimate every other story relative to that one
Example: Assuming a 6 person team composed of 3 developers, 2 testers, and one PO, with no vacations etc., then the estimated initial velocity = 5 * 8 pts = 40 pts/sprint. (Note: You may need to adjust a bit lower if one of the developers and testers is also the Scrum Master.)
In this way, story points are somewhat comparable to an ideal developer day, and all teams estimate 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. Then they have a meaningful way to figure out the 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 be fairly stable, and a team’s velocity is far more affected by changing team size and technical context than by productivity changes. And if necessary, financial planners can adjust the cost per story point a bit. In our experience, this is a minor concern, compared to the wildly differing velocities teams of comparable size may have in the un-normalized case. That simply doesn’t work at enterprise scale, because you can’t base your decision on economics that way.


SAFe builds on the fundamental construct of the iteration, or sprint, as primarily described in classic Scrum and XP.  Teams new to agile can adopt these basic practices. Agile teams can continue to employ their basic Scrum project management practices and XP-inspired technical practices. In this way, they receive the benefits that these proven, effective and largely standard, Agile practices can deliver. In the context of the Agile Release Train and the SAFe enterprise however, the basic iteration pattern operates under somewhat different constructs, including the fact that iterations are synchronized, estimating is normalized as part of the basic economic understanding,  code quality is reemphasized, iteration planning is already seeded with stories from Release Planning, and teams collaborate on system level demos to make sure that the system is sprinting, not just the teams.

Learn More

[1] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009. ​Chapter 14.

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

[3] Cohn, Mike. Agile Estimating and Planning, Addison-Wesley. 2006.

Last updated 20 January, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact