Things done well and with care, exempt themselves from fear.

– William Shakespeare

100% utilization drives unpredictability.

– Don Reinertsen. Principles of Product Development Flow.

This is HIP

 John Lee Hooker


Hardening | Innovation | Planning  Abstract

The concept of a Hardening | Innovation| Planning iteration is necessitated by three major factors:

  1. If the HIP sprint precedes a release, then the hardening activities provide time for final product validation, system and performance testing, standards and security validations, user acceptance testing, and any other Release Readiness activities which are not feasible or economical every sprint
  2. Agile is optimized for rapid value delivery, particularly while in the presence of significant architectural runway. But its highly disciplined model can also impose the “tyranny of the urgent iteration”, and care must be taken to provide scheduled time for innovation, exploration and out-of-box thinking.
  3. PSI/Release Planning is routine and cadence-based as well, as is the Inspect and Adapt workshop and (hopefully) time allocated for continuous education, infrastructure activities and the like. Scheduling these activities during the HIP sprints means that the development cadence can be the same year around, with no special scheduling adjustments required.

There is a fourth consideration as well. From a Lean perspective, we know that full utilization of available resources increases unpredictability of results. A planned hardening sprint, which is not loaded with new value user stories, provides a buffer capacity that adjusts for myriad anomalies in an inherently unpredictable environment, and therefore helps teams meet their PSI/Release commitments even in the face of R&D uncertainty.

And while we have noted that an iteration reserved for hardening allows teams to perform legitimate activities that often are subordinated to code development, such as finalization of product, user, and support documentation and the creation of release communication, we must also caution that teams should never use a HIP iteration as an excuse to defer technical debt such as final system integration, elimination of defects, deferred regression testing, and other activities that should have been performed in earlier iterations.



With respect to the “H” (Hardening in HIP),  let’s consider this as part of “release readiness” and look at these activities from three aspects:

  • Stuff you must do, and probably can do only in hardening
  • Stuff you should be doing earlier, but have to do in a hardening sprint for now
  • Stuff you absolutely should have done earlier, and for which you are using the hardening sprint as a waterfall crutch

Stuff You Must Do in Hardening

In many environments, there are a number of things that must be done, and can only be done (efficiently) during hardening. To name five:

  • Final exploratory and field testing
  • Finalize user, deployment, installation documents
  • Validate solution against release, quality, and standards governance, and any marketing/sales/deployment/operations requirements
  • Create release deployment package
  • Create release communications

Stuff You Probably Should Be Doing Earlier

In addition, especially in the first year or so of transition to agile, the hardening sprint may be used legitimately for a number of other things. These may include:

  • Final cross-component integration and/or integration with third party or customer components
  • Final, integrated, system level testing
  • Final System Quality requirements testing (testing nonfunctional requirements (NFRs) such as performance, reliability, accuracy, load, scalability, etc.)
  • Finalize localization across all required languages
  • Finalize user documentation

Stuff You Absolutely Should Have Done Earlier

And finally, five examples of some of the stuff “you know better than to defer to the hardening sprint (don’t you?).”

  • Final system integration
  • Elimination of P1, P2 defects that remain
  • Automate remaining manual test scripts
  • Deferred regression testing
  • Update user documentation


Many maturing Agile enterpises also recognize that Agile, as powerful as it is, is optimized for reliably delivering end user value on a fixed cadence. Finding time for free association and innovation can be difficult as teams and programs routinely operate under the “tyranny of the urgent” iteration or PSI/Release. To this end, many agile enterprises use periodic HIP sprints for research spikes, infrastructure work and even “hackathons”.

Figure 1 below illustrates one company’s cadence-based process for institutionalizing innovation via “hackathons”. You can see from the figure that the ability to “hack”, is dependent on the ability to routinely deliver a quality release. Not a bad management paradigm?

Figure 1 One Companys Innovation Cadence

Figure 1. One company’s innovation cadence. It’s pretty clear what happens when the Release Candidate has problems.


Planning is the last element of HIP. Advanced scheduling of routine time for continuous education, Inspect and Adapt workshops  and PSI/Release Planning is a hallmark of a maturing Agile enterprise. In many cases, this means that the two week HIP sprint takes on a standard schedule and format, as is illustrated in Figure 2.

Figure 2 Typical Calendar for a HIP Sprint


We’ve seen that HIP sprints provide cadence-based opportunities for Hardening | Innovation| and PSI/Release Planning, without disrupting the annual calendar. While, the Big Picture appears to indicate periodic hardening sprints just prior to the PSI/Release boundaries, the reality is a lot more flexible: individual Agile teams and Agile release Trains can place HIP sprints anywhere, if and when they are needed.

So long as the teams are not “doing the stuff they should have done earlier” during this period, then the program is on the right track while also providing proactive allowances for innovation that can further accelerate value delivery. It’s more fun that way, too!


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, chap. 17.


Last update: 14 March, 2013

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