A Sprint H – Hardening Sprint is a specialized sprint dedicated to stabilizing a software development focuses on correcting vulnerabilities, strengthening the product’s performance, and bolstering its stability. This sprint is typically performed in the later phases of the software development lifecycle, prior to the product’s deployment to production, in order to strengthen the product’s robustness and security. The objective of a hardening sprint is to eliminate any outstanding technical debt and ensure that the product is production-ready.
Sometimes required by QA team often requires the project team to stop working on any new features. All available resources are deployed to stabilising the release
Why it is needed
Hardening sprints happen within organizations that push defect fixes — along with regression, integration, end-to-end and third-party testing — to the end of a project.
A hardening sprint is needed because it helps to ensure that the software product is secure, stable and performant before it is released to production. This can prevent potential issues from arising in the production environment, reduce the risk of security breaches, and improve the overall quality of the product. A hardening sprint also helps to identify and resolve any remaining technical debt, making the product more maintainable in the long run.
It is not encouraged to use a Hardening Sprint, and the requirement for using one ought to be removed entirely by means of improvements in engineering practice. If there is a requirement for hardening, it is recommended that it be completed incrementally using the Cleanup Stories that are included in Sprints rather than devoting an entire Sprint to the task of hardening.
Chris Wright states in SmartBear’s getZephyr blog
The concept of a hardening sprint shares a lot in common with the mindset that underlies waterfall methods. The mere presence of such a task could perpetuate the notion that testing is ultimately something that is done at the end of a production cycle.