Mention having a hardening sprint in certain agile evangelist circles and your ears will probably be in for a hard time!

If your enforcing your definition of done, If each sprint is truly delivering a completed, fully tested, 'potentially' shippable product, If your employing good XP practices with have high unit and integration test coverage and you have a continuous delivery pipeline why do you need a hardening sprint?

If you've answered No to any of the above that's probably why your including them in your planning.

But are Hardening Sprints really that bad? Why do we have the concept of the hardening sprint in Agile if it's an admission that we're not being that holly grail.... 'truly agile'

I've never really found an organisation that is 100% agile (even those that claim to be) often there's an agile delivery aspect wrapped up with Prince 2 - Or an ITIL service orientated department with agile shoehorned in somewhere! My agile friends might tell me that these companies are doing it wrong and need to redesign their entire procedures.... however many companies can't simply make that change overnight.

So what is a hardening Sprint?

A hardening sprint is an additional sprint scheduled in where the team switches focus away from delivering items on to the backlog and concentrates on integration work, tying up loose ends, release documentations/sign-off and handing over to operational teams, etc

Some teams factor an hardening sprint in after a predefined number of sprints (In mind this in an indicator that the agile process isn't working well and should be great big red flag) other teams will factor one in before each release.

Do we need a hardening sprint?

The idea of a hardening sprint really is running against the grain of being truly agile - However in reality many teams probably need a hardening sprint to ensure that 'Done' really does means 'Done', UAT, regression testing (especially when working with older legacy systems) and other sign-off requirements and ensuring that the hardware is actually ready!

One of the better ways to reduce the requirement of 'hardening sprints' is to include some type of continuous delivery pipeline into the UAT/Staging environments - This should help to ensure that bugs are discovered quicker - If possible if you can looking into some of the concepts of Devops this again will help reduce the need for hardening sprints.


So is the hardening sprint a sign that your not doing things right?

If your team is frequently performing hardening sprints - that's probably a sign that your organisation isn't Agile enough! It could be a sign that your Product Owner is not enforcing the definition of done or that your definition of done is failing you and needs to be looked at, Your probably building up technical debt that doesn't appear on your burn-downs charts and isn't being planned for..... Well except for the catchall sprint at the end!

I do however put myself on the pragmatic side of both life and agile project management - I understand the theory, I agree with the theory but I also live in the real world! Many organisations are on a journey to being agile - they can't switch overnight and if a planned hardening sprint results in higher quality software being delivered - still within a time-boxed schedule is it really that bad a thing?

If your using your hardening sprints to fix known issues or complete features that are known to not be fully working than your not enforcing your teams definition of done and something is wrong which you should address.

However - If your factoring hardening sprints to allow for unknown issues and bugs that might arise, using the hardening sprint to hand over to operations teams and to do the necessary release sign offs than within reason I don't have a problem with the concept.... And it's probably a nice change for your Scrum team!