In Dean Leffingwell's Scaled Agile Framework there exists the concept of a hardening iteration E.G. after three sprints of two weeks duration, we have a hardening sprint of one week.

In this short sprint we can pay back some of the technical debt accrued over the previous sprints, ensure more rigorous integration testing is carried out and the set up, tear down procedures are quality reviewed. Time can also be factored in for any training requirements that were uncovered over the prior three sprints.

Admittedly, if we have a mature DOD on the delivery of a sprint work item there should be a decent level of quality but sticking to the principle that we deliver only what is required to satisfy the criteria of each story will eventually lead to known duplication in the code base. Good developers will naturally want to improve their code base so having a hardening sprint will ensure they can concentrate on moving WIP in the main sprints but the address any wider re-factorings periodically.

I recently attended a conference where Rachel Davies of Unruly Software explained that their XP developers have every Friday as Golden Time where they are free to re-factor the codebase and learn new technology. That works out at one day in 5 as opposed to the one day in seven by having 3*2 week sprints plus a hardening sprint.

I believe this is a good approach to paying the technical debt in a managed fashion. Technical debt will become more expensive to repay the longer the project continues in the same fashion as a story becomes more costly to change once we have delivered.

I know the idea of a hardening sprint is anathema to agile purists but I think it works well in our pragmatic scrumban approach.

I think the issue is similar to that around the validity of having a Sprint Zero which ruffles a few feathers.

So, Question is:

Is a Hardening Sprint a good idea, if not why and how would one address the concerns outlined above?

  • Other meaning of hardening: You have a releasable product, but there's a new requirement for it to be able to work on a old computer in a well being attacked by lightning. I assume we aren't taking about this. – Nathan Cooper Aug 28 '15 at 13:11
  • I don't think this warrants a full answer, but for your point on refactoring, I'd look at how TDD handles refactoring, where it's worked into the coding process, not something you have to do later. – Daniel Aug 28 '15 at 19:06

Hardening Sprint should only be for stabilizing the system and getting it ready for release

In my previous job we ran a one week hardening sprint prior to deploying the content of 2 or 3 two-week sprints to a production web site. At that time we were doing manual regression testing. There was not enough regression testing done within the sprint to be sure it is shippable. So, during the hardening sprint all we did was regression testing. If any bugs are found, we will fix them and verify them.

Eventually we hired a team member with test automation skills, built a regression test suite. We also used some of these tests to run load and stress testing. Then we did away with the hardening sprint.

Mike Cohn advocates the same thing, "The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur."

If you are doing code refactoring during the hardening sprint, I would say that is a red flag or to use your own term a "witches brew"! You are creating more chances for regression issues.

So, you may need a hardening sprint when you are on training wheels. Once your engineering practices improve to assure a shippable increment in each sprint, you can drop it.

  • Not so sure about re-factoring bringing more regression issues but I suppose that would depend on the level of unit tests the code had been developed to. Our teams are invested in TDD and the hardening would involve rigorous regression testing as a given. As for the training wheels, I reckon that's a good point but probably more to do with the maturity of the platform and managed code-base the developers are familiar with than the actual agile process. – El Toro Bauldo Aug 28 '15 at 13:29

Whether it's good or bad idea depends on how you manage risks connected with it.

From what I have experienced the risks are:

  • refactoring effort is often hard to estimate and leads to planning problems
  • it's hard to define acceptance criteria for the refactor
  • there is a lure to deliver half-ass stories (rather than half-done) at the end of the sprint with belief that "we can fix it later". That is especially true for Golden Time that happens right after the sprint

Another thing to bare in mind is that someone have to manage backlog items related to refactoring. More items in the backlog means more time spent on debating whether this refactor is more important than the other one.


A hardening sprint is a tool. If you use the tool correctly it is a good idea. If you use the tool without knowing the problem you are trying to solve it may or may not be a good idea.

That's a vague answer so in practice:

If you have a team that isn't ready to continuously build quality into their product (i.e. they have accrued a ton of tech debt or the business is not allowing enough slack to prioritize tech debt, learning, and CI into the regular iterations) then a hardening sprint is a good tool to address the tangible issue that product quality is suffering or the delivery team is not given enough time to learn and improve.

I'd argue it is ideal to shoot for teams that deliver high quality and have time for CI in every iteration (if you're in a Scrum world) or continuously (if you're in a Kanban world). I'd say hardening sprints are an intermediary solution to getting to a sustainable development model. They are also great for bringing light to quality problems since having a hardening sprint for a few weeks can be a costly pill for management and the team to swallow when they have 1-4 weeks of 0 business value delivered.

The downside of the hardening sprint is that hardening sprint activities are usually more efficient and/or effective to address right when the problem occurs. There is a ramp-up cost associated with hardening iterations that is lower if quality/CI are built into each iteration or work item.

  • This x 1000. Agility is a spectrum, and teams have to start somewhere and move across it over time. The only sin would be settling for hardening sprints as "good enough" and not trying to grow past them to become more agile. :) – Jeff Lindsey Sep 1 '15 at 15:43

No. It's not a good idea

Just a few questions.

"so having a hardening sprint will ensure they can concentrate on moving WIP in the main sprints "

  • So until this hardening sprint is done is the previous work shoddy and unreleasable? Ie, not Done To put it another way, the goal of a sprint should be to produce a potentially releasable product and if you haven't done this you've failed.
  • Are your development team being put under pressure to move work across the board in a shoddy fashion?
  • If a developer did buy into this and do shoddy work how could you 'promise' to fix it later and still remain responsive to change and customer needs?

I'm also not sure that your view of re-factoring is quite correct. It's not just a cleaning activity. An agile project begins with a simple domain model. A model that isn't sophisticated enough for the eventual system (but that's a good thing, because you don't need that yet and don't know what it needs to be). Re-factoring belongs in with the work, because the design of the code is meant to evolve as it grows. I'm not sure it's a terribly good idea to encouraging developers to move the WIP and do the domain design evolution later. Ron Jeffries explains it better. Refactoring isn't distinct from the work, it's just a mandatory thing you have to do to successfully push your product forwards.

Golden Time: This isn't the same as hardening. It's more about trying new stuff out in the code base, not cleanup.

More Ron Jefferies: Refactoring -- Not on the backlog!

  • Yes Nathan. The work is done to the satisfaction of a rigorous DOD. However, a good developer could almost always improve a code class every visit but good enough is what we are aiming for in the sprint. Nothing in my text about shoddy work, see DOD. Also, there is no rule about starting from a domain model, although that is usually the one class of code that straddles each distributed layer. The point I'm trying to get across is that having this sprint is a pragmatic approach to managing the technical debt. – El Toro Bauldo Aug 28 '15 at 13:21
  • 1
    @ElBauldo Your first statement cannot be true. If it was done to a good enough standard we wouldn't be taking about hardening sprints. Your developers should be improving classes every time they touch them, that's what the whole continuous improvement (read the Ron Jeffries link) is about. – Nathan Cooper Aug 28 '15 at 13:26
  • Not really @Nathan. If we have five developers working a two weeks sprint I wouldn't imagine they had time to scrutinise every line of code checked in to determine if they should apply a wider refactoring a la the rule of three >>>> Rule of three is a code refactoring rule of thumb to decide when a replicated piece of code should be replaced by a new procedure. It states that the code can be copied once, but that when the same code is used three times, it should be extracted into a new procedure. The rule was introduced by Martin Fowler in Refactoring and attributed to Don Roberts.) – El Toro Bauldo Aug 28 '15 at 13:33
  • "wouldn't imagine they had time to scrutinise every line of code checked in" I think developers should be checking in good code, not excuses. Refactoring it not a special seperate process and it's so much more than extracting stuff into methods, the book your referencing is massive and doesn't boil down to "the rule of 3". Out of interest, what is your role in your team? Are you a developer? – Nathan Cooper Aug 28 '15 at 14:20
  • I was about to ask you the same question Nathan. I'm the development manager but I'm getting the feeling you've never been a developer. I need to repeat that there is nowhere above that I have talked about shoddy or bad code being produced to satisfy WIP. This is a strawman argument. Duncan Green on linked in has a very good take on what I'm trying to get across. www.linkedin.com/pulse/death-systems-agile-fallacy-duncan-green – El Toro Bauldo Aug 28 '15 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.