Hardening Sprints: The Good, Bad, and Downright Ugly

You are here:

I remember the threatening email as if I had received it yesterday. I was in my home office on a Saturday when it showed up in my inbox, a message from one of the world’s leading scrum trainers and coaches. Basically, he threatened my certifications in the email unless I “ceased and desisted” talking about hardening sprints. He was adamant that the concept was not part of the core scrum definition and I had no right to talk about it. He had even copied the Scrum Alliance on the email.


For the record, I had been talking about the notion of “hardening sprints” for several years. Not from some academic perspective, but because I had made use of them in a wide variety of agile contexts and found them to be a useful variation of release tempo. I had given a presentation at the Agile Conference in 2007 and at several of SQE’s Agile Development Practices conferences. So my ideas were “out there” on the web and in the minds of attendees. The person doing the threatening may have thought I was a Certified Scrum Trainer at the time, which would have meant he had more contractual control over what I said and did with respect to Scrum. In fact, I was not certified at the time so he had little leverage over what I said – it being America, the last time I checked. I politely and respectfully ignored his request and continued my agile journey. However, I must say it was a disappointing and scary moment.

Why do I share this story?

I tell it to illustrate the historical passions around this concept in the Scrum community and beyond. This is a fairly contentious topic, one that often brings out the worst in our agile community. I also believe it is one that needs definition, explanation, and clarity around the contexts where “hardening sprints” might, just might, be a useful tool in your agile arsenal. That is the intent of this article so please keep an open mind to the possibilities.


Contact us to learn more about how Zenergy’s Agile transformation services can help you.



Moving On...

As we move on, I think it best to establish terminology and a definition. There are no clearly agreed definitions for hardening sprints—probably because they have been generally discouraged. I will establish my own definition as a baseline.


A Hardening Sprint is defined as a sprint focused on “catching up” on technical test debt and readying a Scrum-produced release. In this case, it typically focuses on completing testing activities such as integration, system, and full regression testing. Frequently it includes some final defect repairs as well. Often, hardening sprints are more useful in multi-Scrum team product releases or Scrum at scale.

While there are probably many terms used for these sorts of sprints, I have found the following four most commonly used:


  • Hardening Sprint – implying that the team is “hardening” the application prior to release, focusing on testing and defect repair. This seems to be the most commonly used term for this sort of sprint.
  • Stabilization Sprint – similar to the focus of the hardening sprint, I believe “stabilization” was simply an alternative term intended to avoid some of the ”heat” associated with the term hardening.
  • Release Readiness Sprint – Mike Cohn has shared this notion of a sprint that is focused on release preparation specifics. Again, a softening or repurposing of the term, but it has the same intention. Dan Rawsthorne, check the references, has coined the term “Release Sprint” which seems quite similar to this one.
  • Spring Cleaning Sprint – I came upon this definition while researching this article. This is a more expansive definition that allows for more than testing and defect repair. For example, you could easily focus on refactoring core code or infrastructure in this type of sprint.

While they are all quite similar, there are some unique nuances in their definitions. The most common terminology is “hardening sprint,” the terminology that receives the most criticism in the community. Let’s explore why the notion gets so much negative press.


Why the Dreaded 'Hardening Sprint'?


hardening-Sprints-part-2 (2)I believe there is a similar reaction to a hardening sprint as there is to a Sprint #0. In Core Scrum¹, the notion of a sprint or iteration is a general-purpose construct. It is intended to take a set of product backlog items (PBI’s) and produce a “potentially shippable product increment” at the end of each sprint. This intent, producing an executable increment, is central to the essence of Scrum.

The hardening sprint conceptually disrupts this. It is a periodic thing that is specially focused toward previously produced content.

If you take a pure LEAN view to things, the team has a responsibility for “hardening” the software within the sprint in which it was produced, so deferring work to hardening can be quite wasteful.

Hardening usually operates on a series of previously delivered sprint increments. So, by definition, these sprints were incomplete and sort of “broke the rules” of Core Scrum. Using the term “sprint” as part of the terminology exacerbates the problem. This can confuse novice Scrum users to think it’s a “part of” or an “acceptable extension to” Core Scrum, when it certainly is not.

From a definition-of-done perspective, you are also deferring completing stories. I would argue you are only deferring areas that would potentially be impossible to complete within the constraints of a sprint, but, nonetheless, the work is not completely “done” until the end of “hardening.”

Finally, there has been discussion surrounding how it “games” the reporting of progress to your stakeholders. Again, since the software is not completely “done,” how can the team take credit for it as a deliverable or count it in their velocity? I wholeheartedly agree it muddies the water again here as well.


Get Out of Jail Free Card


I have also heard of hardening sprints being used as a “get out of jail free card” within Scrum teams. The conversations are usually along the following lines:

  • We don’t have enough time to test that component properly, so we’ll do it in hardening
  • We don’t have time to fix all of the cosmetic bugs we produced in this sprint, so we’ll do it in hardening
  • Let’s defer customer support training entirely to hardening
  • The design is still too volatile to document. We’ll wait until it stabilizes and document it in hardening

You see what is happening? Hardening can undermine the broad definition of done that is so incredibly important to Scrum’s quality and delivery dynamics.

But if it is so bad, why do it at all? To answer, let’s explore some of the contexts where hardening might not only be a good idea, but almost required.


While teams most often aim to finish every item within a given sprint, for numerous reasons, that isn’t always the case.

Watch this short video for insight as to why quality matters most in agile organizations.


Conceptual Support


Let’s first look beyond my perspective. There are people who have come out in support of the notion of hardening sprints.

One person who supports them is Dean Leffingwell in his Scaled Agile Framework or (SAFe). Dean created the notion of a “Release Train”, which is a higher-level tempo beyond the sprint or iteration. Typically, it is a series of sprints that are targeted toward release. They include hardening sprints as an endgame practice to stabilize the software prior to release. Dean has wrapped the release train and hardening sprints as practices within his SAFe framework. He first published the idea in his 2007 book Scaling Agile and it does help advance the support and sensibility of hardening sprints in specific contexts – one of them being “at scale” agile projects.

Another proponent of phasing development-centric iterations into release readiness is Scott Ambler in his Disciplined Agile Delivery (DAD) model and related book. Conceptually, Scott wraps hardening activity into his Transition Phase. A big part of transition is hardening the product with more mature testing activities and defect repair. Again though, this does not preclude doing a good job of iterative development, risk-based testing, and fixing bugs along the way.

Both SAFe and DAD are targeted towards larger scale and enterprise-level product development. So it makes sense for them to include the notion as these contexts align well with the need for hardening iterations.

I am certainly not lobbying for hardening sprints to become a part of “Core Scrum: as a globally applied practice. I can clearly envision many contexts where they are not that useful or helpful. For example, small team practices where the results of every sprint are released, are clearly not candidates for the use of a hardening sprint. And I do believe it requires maturity and balance to use them effectively, something not all organizations are ready for.


Hardening Contexts

But there are many contexts where hardening can be incredibly useful. Here are a few of these, just to set you up for healthier applications:


Wrapping Up


These sorts of sprints are considered a ScrumButt³ or Scrum anti-pattern by many of the leading Scrum authorities (CST’s and CSC’s). I get that. I am not trying to promote them as a part of “Core Scrum.” Nor am I promoting them as a best practice. However, I do believe they are part of what is starting to be called a Generally Accepted Scrum Practice or GASP. These are practices that, while not part of Core Scrum, have proven to be useful and valuable in specific contexts.

There is one final point I would like to make. In my reading, I believe it was one of the comments in footnote 2, someone said that the goal should be to continuously reduce the time and focus of the hardening sprint, to the point of removing the need for one. I absolutely agree! One way to do that is by investing in test automation. Another is by continuous improvement that produces higher quality designs and code.

The point is, I clearly acknowledge hardening sprints are waste that must be reduced and eliminated over time. While I am not sure if every team and organization can effectively take their use to zero, having the intent to continuously reduce them is a healthy pattern extension from my perspective.

And to avoid all of the contention, perhaps we simply rename them as a hardening iteration or release readiness iteration and take “sprint” out of the terminology. That would remove any direct connections with “Core Scrum” and avoid confusion. Personally, I like the “release readiness” terminology as it is coupled with release execution and delivery.

I hope this article has helped broaden your understanding of these sorts of sprints and balanced your view. I do not look at them as either good or bad, but something contextually in between.

In the meantime, stay agile my friends!



Up Next: 


1 When I say “Core Scrum” in this context, I am truly speaking about its definition in two distinct references. From Scrum.Org, how it’s defined in the Scrum Guide. And from the Scrum Alliance, how it’s defined in the Agile Atlas. The Atlas has at least established the notion of “Core” Scrum and is THE reference for the Certified Scrum Master (CSM) certification.

2. I have written an article here that explains the notion of Technical Test Debt in much more detail: http://rgalen.com/s/Technical-Test-Debt-TTD-Explored.pdf

3. Here’s a link to a good explanation of the history around ScrumButt and the “test”: http://www.leanagiletraining.com/blog/category/scrum-butt/


For Further Reading

  1. Here is a perspective on the Scrum.org site. As you can imagine, since Ken Schwaber is not leading Scrum.org, the practice is not supported – http://www.scrum.org/Forums/aft/307
  2. Here is a link to Mike Cohn’s notion of a Release Sprint – http://www.mountaingoatsoftware.com/blog/correct-use-of-a-releasesprint
  3. More information on SAFe can be found here – http://scaledagileframework.com/
  4. An article I wrote with some early reactions to SAFe – http://rgalen.com/s/PM-Times-Article-Dont-you-dare-play-it-SAFe-bnmf.pdf
  5. More information on DAD can be found here – http://disciplinedagiledelivery.com/