Hardening Sprints: The Good, Bad, and Downright Ugly

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.

Talk Nerdy to Me

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:

Distributed and At-Scale Agile: It is easy to say that a team should “integrate” their software fully within each sprint. But what if you have 20-50 teams working on the same project and the teams are geographically distributed? Sure, you want to try to integrate as much as possible across the teams, but clearly you are not going to do it all. It just does not meet reasonable ROI on a sprint-by-sprint basis. In these cases, having a hardening sprint focused toward full Integration, regression, and system testing might be a prudent trade-off.
Customer Receptivity: Something that gets lost in the “potentially shippable product increment” goal that is such a strong part of Scrum is… what if your customer simply cannot tolerate or accept a release every 1-2-3 weeks? What do you do then? Many domains and customers simply cannot. The game is then to accumulate partial release content over the course of several-to-many sprints. But then there is the need to re-qualify all of that code when you are ready to do a real (not potential) release.
Test Automation Coverage: Having high degrees of test automation, and automation in general, is one of the ways that agile teams can truly go fast. It provides a wonderful development safety net and gets feedback to the team quickly. But what if you do not have it? What if you are currently stuck with thousands of manual, albeit valuable, test cases to run? Clearly if you run all of them within each sprint you would derail the focus. But running risk-based regression and functional testing is risky since you are deferring levels of coverage. A hardening sprint is a solid way to handle this technical test debt² before releasing.
Skewed Sprint Consolidation: In many agile contexts, some work is done a “sprint ahead” of other activities. For example, UX design is often completed by a design Scrum team and then handed off to a front-end implementation team for coding in a follow-on sprint. This sort of staging often happens with research (story spikes), design, architecture, and other up-front activities in projects. The hardening sprint is a place to check that all of these skewed activities have come together into a cohesive package from a customer perspective. It certainly should not be the first or only time, but it can serve as a design convergence point.
Defect Rework: At the end of the day, bugs are discovered pre-release whether you are implementing Waterfall or Agile methods. If you are doing Agile well, then you are finding fewer and the rework cycle time is much shorter. But, inevitably, some cleanup of bugs pre-release is fairly normal. Reserving time in your hardening sprint gives you some time for final defect cleanup before making the release.
Deployment Readiness and Training: There is much work required to get a release out the door in many organizational contexts and business domains. I think one of the things that “potentially shippable product increment” does is to trivialize this level of pre-release preparation. While my definition of hardening sprints tends to be more testing and defect-repair focused, it is an interval that allows time to prepare software for… wait for it… release! Dan Rawsthorne has written an article on the Agile Atlas site entitled Out the Door: the Release Sprint, which is perhaps another name for a hardening sprint. Dan focuses the sprint on this area though, finishing all of the details surrounding actually releasing a supportable product.
Regulations, Governance, and the Art of Trivialized Agile Testing: Finally, another focus for a hardening sprint is making all of the steps and creating all of the obliged artifacts that meet your internal and external regulations for the product. Consider it a “governance acceptance test” checklist where various requirements are exercised and confirmed. Quite often this includes a full regression test that provides traceability between the project requirements (User Stories?) and the tests that covered that functionality. In many domains, financial and healthcare for instance, proof of completeness and following your predefined processes are required steps pre-release.

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!

Bob.

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

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
Here is a link to Mike Cohn’s notion of a Release Sprint – http://www.mountaingoatsoftware.com/blog/correct-use-of-a-releasesprint
More information on SAFe can be found here – http://scaledagileframework.com/
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
More information on DAD can be found here – http://disciplinedagiledelivery.com/

Our Future AI Overlord’s Take on Agile
January 24, 2023

Agile Mindset: The Biggest Impediment to...
September 19, 2022