Using Hardening sprints in Agile Development | David Tzemach
Updated: Jun 29, 2022
In theory, an Agile team is expected to produce a potential software increment at the end of each sprint. This looks great on paper, but the system sometimes doesn’t meet the quality standards, and further testing is needed. This is the time for hardening sprints.
What Is a Hardening Sprint?
A hardening sprint is an additional sprint placed after the regular development sprints that the team uses to stabilize the code and ensure that the system is ready before being released and deployed on customer environments.
Hardening sprints should focus on system stabilization, integration, and overall preparation of the product for release, not on delivering new features. We still expect our teams to complete all their tasks within the boundaries of the regular sprints.
Therefore, you must ensure that the hardening sprints meet their purpose and goals. A common pitfall is that hardening sprints are hijacked by the teams for different purposes.
There are differing opinions about the necessity of hardening sprints in the world of an incremental development approach. In theory, Agile teams should finish all development activities within the regular development cycles. However, in reality, many factors, like the existence of a legacy codebase or a lack of a CI/CD infrastructure, make it almost impossible to keep up with the pace of rapid releases that meet expected quality standards.
When Should We Use Hardening Sprints?
The real question is not the necessity of hardening sprints, but what they should include and how often we should use them. There is no best practice for determining the exact pace for hardening sprints, as there are just too many factors unique to each project. However, here is a simple heuristic for doing so.
The Scope and Activities of a Hardening Sprint
We should stop thinking about features in hardening sprints and focus on stabilization activities. Here are some of those activities:
Completing all the quality activities not finished in the regular development cycles. Examples include: improving system documentation, improving error handling (although that should be part of the regular development cycles), code cleanups, re-checking the system configuration files, conducting final quality reviews and ensuring the existence of clear guidelines on how to deploy the system.
Deployment and configuration of the product in a production-like environment to simulate real customer use and ensure that everything works end-to-end.
Setting up a recovery plan in case of deployment failures includes rollback scripts and recovery procedures.
Conducting quality and testing activities that are difficult to perform in the regular development cycles, including field testing, final quality sign-off, non-functional testing (focusing on performance-related aspects such as load, stress and scale testing), fixing bugs and more.
Educating and training support teams will guide customers on how to use the system.
Benefits of Hardening Sprints
Although needing hardening sprints sometimes indicates the team’s immaturity, they still add some great benefits.
A hardening sprint ensures that the team completes all the different test activities that increase the quality of the product.
It allows Agile teams to perform end-to-end testing of the system, whereas previously, their focus was on the narrow perspective of delivering specific features.
It allows the team to focus on non-functional testing (performance, scale, usability, etc.) that are usually not part of regular development cycles.
It allows Agile teams to test the system on more complex environments that are not accessible to the team in regular development cycles.
It allows the Agile team to fix the remaining regression bugs to increase the overall quality and stability of the system before deploying to customers.
Hardening sprints mean that the business will have more time to prepare and communicate the different aspects of the release.
As you can see, there is a sense in using hardening sprints, but this should never be your goal. The goal should be to take hardening-sprint usage to zero. To do so, you must implement strong CI/CD systems and use both development and test techniques to make the overall development process more efficient.