The Scrum Guide says that at the end of each sprint a “potentially shippable” increment of software should be delivered by the scrum team. But what happens when system dependencies and other release constraints make shipping impossible? Enter the “hardening sprint”.
A hardening sprint is a specialized sprint where scrum teams work on things such as: integration testing, performance tuning, security reviews, and localization.
It is not a catchall for new features, sloppy code, bug fixes, and other work that signals poor craftsmanship. Be on alert for some of these common misuses:
- We ran out of time and didn’t full test this feature, we’ll finish testing during the hardening sprint
- User documentation didn’t quite get done for this feature. I’ll finish that up during the hardening sprint
- No need to engage support | security | infrastructure now, we’ll bring them up to speed during the hardening sprint
These abuses are why many of the scrum gurus will tell you that hardening sprints are an “anti-pattern” or just flat out bad. A quick google search reveals past flame wars and pointed blog post demeaning the use of hardening sprints. This volatile territory. You’ve been warned.
However, I do not agree that scrum teams who use hardening sprints have lost their way.
It is true that by using a hardening sprint, the scrum team is admitting that they did not deliver “done” software during their preceding sprints. This is an indication that their definition of done is lacking. This could be an impediment to the team’s future success.
But this could also be an intentional decision by the organization. A pristine definition of done is expensive. Continuous integration, high test coverage, and strong devops organizations take time to build and implement. Along with a lot of money. During the early stages of an agile transformation, hardening sprints may be mandatory due to some or all of these practices not being in place. This is ok, but please keep these 3 important ideas in mind when deciding to use a hardening sprint:
- Be transparent with the Product Owner about what “done” means: If “done” isn’t true until after the hardening sprint, the Product Owner has the right to know. Being open about why the hardening sprint is necessary will allow the PO to make better decisions about releases and ensure that their forecasts and product planning are more meaningful.
- Don’t abuse the practice: A hardening sprint isn’t a free pass to be lazy. Keep the work within the hardening sprint to a minimum and continually be on the lookout to reduce the work that is necessary to complete in hardening sprints.
- Reduce the reliance on hardening sprints over time: Your goal should be to eventually eliminate the use of hardening sprints. In some organizations this will not be possible due to various constraints, however, continually inspecting the reason for sprints and looking for ways to reduce their frequency and duration can help the scrum team get value delivered faster to their customers.
The bonus idea to wrap things up is to make sure that your decision to use a hardening sprint is intentional. By that I mean that scrum teams should have a plan for conducting hardening sprints and a long-term goal to eliminate them to the extent possible. If left to chance, many of the bad practice mentioned earlier can and will creep in to your hardening sprints.
Question: I’d love to hear your thoughts and experiences on hardening sprints. Do you use them? If not, why not? If so, how have they helped your team? You can leave a comment by clicking here.