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…
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.