One step at a time is good walking.

Old Chinese proverb

Plan. Do. Check. Act

E. Deming

Iterations Abstract

Agile development methods (except for kanban) 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. 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.

Details

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 PI. 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 PI Objectives. Timeboxed 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 from the team to the sprint goals
  • 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:

  • Storyboard/BVIR – The teams storyboard 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 storyboard helps the team easily identify what’s remaining in order to successfully complete the iteration. In addition, the storyboard can also serve as a reminder for limiting work in process (some teams place WIP limits on each state). (Note: While most enterprise teams apply effective agile project management tooling to the tracking challenge, the visual storyboard is usually kept as a boldly-visual, kinesthetic, and helpful progress indicator.)
  • 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.

Summary

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 14 July, 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 permissions@ScaledAgile.com.