The majority of scrum practices recommend that at the end of each sprint you should have a potentially deliverable increment of software. But what happens when release constraints, system failures and other dependencies make on-time, finished delivery impossible? That’s when you insert your hardening sprint.
Hardening sprints ensure that Done really does mean Done. In a hardening sprint, the team stops focusing on delivering new features or architecture and instead shifts their time and focus on system stabilization, integration testing, performance tuning, security reviews and overall preparation of the system for release.
You must keep a watchful eye to ensure that hardening sprints do not become a catchall for “re-doing” sloppy code and bug fixes. A hardening sprint is not a free pass to be lazy or a “get out of jail free card.” Try and keep the work within the hardening sprint to an absolute minimum and continually attempt to reduce the work that is necessary to complete in hardening sprints.
How does one know if a hardening sprint is right for their company or their type of work? Let me break it down for you here. Hardening sprints…
- Allows QA to perform end-to-end testing of the application, where as previously QA was focusing on specific features and stories.
- Allows dev to fix any regression defects to achieve a stable quality build with which you can go-live. At the end of the day, no one is perfect, and bugs are discovered pre-release whether you are implementing waterfall or agile methodology. Inevitably, some cleanup of bugs pre-release is normal and to be expected.
- Allows QA to test the system in a like-production environment, with all 3rd party interfaces.
- Allows for stress testing, load balancing and performance testing, all tests that are typically expensive to setup and complete.
- Allows for deployment readiness and training. Depending on what you are deploying, a lot of work can be required to get a release out the door in many organizations and business domains. This hardening sprint allows the team to focus on finishing all the fine details surrounding the release of a supportable product.
- Allows your customer time to accept the release. Truth be told, many customers simply cannot tolerate or accept a release every 1-2-3 weeks. You many find yourself accumulating partial release contents over the course of several/many sprints. This hardening sprint allows you to re-QA all that code when you are ready to do a real release.
- Allows for regulatory governance acceptance. In many domains, financial and healthcare for instance, proof of completeness and following predefined processes are required steps for pre-release.
- Allows for communication. Large corporations can find it challenging to adequately communicate a release along with all planned and packaged release items. A hardening sprint provides the time to properly communicate and formulate release notes so all parties are informed of upcoming items.
Continuous integration, high test coverage and robust DevOps organizations take time and money to build and implement. During the early stages of agile, hardening sprints may be required as some or all of the aforementioned practices are not yet in place. As time evolves, the team will mature and a seasoned agile team will shrink the number of required hardening sprints. Dev understands the need to fix high priority bugs as they go and QA understands the need to test closer and healthier early up in the release cycle.
In closing, I am not 100% convinced that every team and organization can effectively take hardening sprint usage to zero; however, having the commitment to progressively reduce them is a healthy objective.