Inertia is the residue of past innovation efforts. Left unmanaged, it consumes the resources required to fund next-generation innovation.
—Geoffrey Moore

100% utilization drives unpredictability.
—Don Reinertsen

Innovation and Planning Iteration

The Innovation and Planning Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI objectives, provides dedicated time for innovation, continuing education, as well as PI planning and Inspect and Adapt (I&A) events.

SAFe provides a dedicated focus on continuous delivery of customer value. To that end, during PI execution, teams are busy working on the Features they committed to in PI Planning. Every Iteration counts, and the teams are mostly “heads down,” focused on near-term delivery. One Iteration after another, the Solution marches closer to market. The focus on delivery is unrelenting.

Of course, a focus on one thing—delivery—can lead to a lack of focus on another—innovation. Given the constant urgency for delivery, there’s a risk that the “tyranny of the urgent (iteration)” will override any opportunity to innovate. To address this, SAFe provides dedicated Innovation and Planning Iterations.


Understand the IP Iteration Activities

Innovation and Planning Iterations provide a regular, cadence-based opportunity every PI for teams to work on activities that are difficult to fit into a continuous, incremental value delivery pattern. These can include:

  • Time for innovation and exploration, beyond the iterations dedicated to delivery
  • A dedicated time for the PI System Demo, Inspect and Adapt workshop, PI Planning events, and backlog refinement, including final prioritization of Features using WSJF
  • Final integration of the Solution, if releasing on the PI boundary
  • Work on technical infrastructure, tooling, and other impediments related to the system
  • Enablement of continuing education

In addition, IP Iterations fulfill another critical role by providing an estimating buffer for meeting PI Objectives and enhancing the predictability of PI performance.

Agile Release Trains typically report that their overall efficiency, velocity, and job satisfaction are all enhanced by regular opportunities to “recharge their batteries and sharpen their tools.”

Allow Time for Innovation

One of the pillars of SAFe’s Lean-Agile Mindset is innovation, but finding time for free association and innovation in the midst of delivery deadlines can be difficult. To this end, many enterprises use IP iterations for research and design activities and hackathons. The rules for a hackathon can be simple:

1. Team members can work on whatever they want, with whomever they want, so long as the work reflects the mission of the company
2. They demo their work to others at the end of the hackathon

The learning from hackathons routinely make their way into Program Backlogs and often help drive innovation. They’re fun, too!

Dedicate Time to PI Events

The PI system demo, inspect and adapt workshop, and PI planning are critical events that take time to execute. Placing them in a dedicated IP iteration means that all other Iterations can have normal lengths and velocities and are not impacted by the time dedicated to these critical functions. Even more important, the events can be held on a cadence, so that their occurrence is better guaranteed.

In addition, it’s likely that some just-in-time, last-responsible-moment Program and Solution Backlog refinement and Feature and Capability elaboration during this period can significantly increase the productivity of the upcoming planning session.

Integrate the Complete Solution

The IP iteration contains the final system demo of the program increment and provides time for final testing of the Solution, including final performance and other Nonfunctional Requirements (NFR) testing, standards and security validations, user acceptance testing, final documentation, and any other readiness activities that are not feasible or economical to perform at every iteration.

When a complex solution includes hardware (and other components) that are more difficult to continuously integrate end-to-end, full integration at the Program Level, as well as the Large Solution Level, may be feasible only during the IP iteration. In these cases, it’s just common sense to plan for that.

That being said, this should not be the only attempt to integrate the assets into the system. SAFe organizations rely on frequent integration, which—even when not fully end to end—addresses specific aspects of the solution and validates the assumptions early enough to be able to respond to significant problems and risks within the PI. These integrations are demoed at the system demo at the end of every iteration. The IP iteration is a placeholder for full, final solution integration that must happen at least once per PI. The System Team(s) typically assists the Agile Teams with this integration effort.

Advance Development Infrastructure

Lean delivery puts additional pressure on the development infrastructure. New continuous integration environments must be provisioned, new test automation frameworks must be implemented and maintained, agile project management tooling is adopted, intra- and inter-team communications systems may need to be upgraded or enhanced, and the list goes on.

While many of these items can and should be addressed in the course of each iteration (they are often improvement stories from the team’s Iteration Retrospective or Enablers), it can be more efficient to perform an upgrade or migration at a time when there isn’t a critical demo just a few days away. We all understand that we have to sharpen our tools from time to time; Agile Teams are no different. Indeed, they have an even higher dependency on their working environments than do regular teams, and so they need to spend time building this environment and continuously improving.

Enable Continuous Learning

Lean engineers and leaders are lifelong learners. Changes in technology, as well as changes to method and practice, are routine; opportunities for continuing education, however, are far less common. In addition, the initial move to Lean-Agile requires many new techniques and skills, including:

Making time for continuing education gives teams and leaders a welcome opportunity to learn and master these new techniques. This time can also be used to launch and support Communities of Practice devoted to these and other topics. The net results benefit both the individual and the Enterprise: Employee mastery and job satisfaction increase, velocity goes up, and time to market goes down.

Leverage the Built-in Estimation Buffer

Lean flow teaches us that operating at “100% utilization drives unpredictable results” [1]. Simply put, if everyone is planned to full capacity, there is no one available to flex when problems inevitably occur. The result is unpredictability and delays in value delivery. To address this, the IP iteration is treated as a “guard band” (or narrow buffer) to prevent work from the current PI from interfering with the work in the next PI . During PI planning, no features or stories are planned for development in this iteration. This buffer gives the teams extra time to respond to unforeseen events, delays resulting from dependencies, and other issues, thereby increasing their ability to meet Team and Program PI Objectives. This substantially increases the predictability of the program’s outcomes, an attribute that is extremely important to the business. However, routinely using that time for completing the work is a failure pattern. Doing so defeats the primary purpose of the IP iteration, and innovation will likely suffer. Teams must take care that the estimating guard does not simply become a ‘crutch’.

A Sample IP Iteration Calendar

Taking all the above into account, many teams’ IP iterations take on a somewhat standard schedule and format. An example is shown in Figure 1.

Figure 1. Example calendar for an IP Iteration

Learn More

[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

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


Last update: 17 July, 2017