Hardening Sprint
[hahr-dn-ing sprint]
Definition of Hardening Sprint
A Hardening Sprint is a specialized sprint dedicated to stabilizing the code base so that it is robust enough for release; it is often necessary because the Team failed to use an appropriate Standard of Care when it did its work. Using a Hardening Sprint is not recommended, and the need for it should be eliminated by improving engineering practice. If the need for hardening exists, it should be accomplished a little at a time by using Cleanup Stories within Sprints, not by dedicating a complete Sprint to hardening.
Examples
Teams that are faced with an excessive amount of cleanup work such that a whole sprint must be dedicated to stabilizing the code base often enact something called a hardening sprint. This is a indicator of immature software development practice.
Of course you have automated tests for each fixed feature, you should have automated tests for ALL features. Also, never, never, never, have a hardening sprint. Have cleanup chores in every sprint until it's clean enough. That's my advice.
Great engineering teams avoid things like hardening sprints by doing things such as continuous integration, adopting XP practices, automating regression tests and adhering to a strict Standard of Care.
Discussion
Avoid Hardening Sprint by doing Chores. Chores are work that just needs to be done in order to be successful at developing actual Product. One way I look at it is that Capabilities are things we do in order to provide value to Stakeholders, and Chores are things we do in order to maintain the Team’s ability to provide those Capabilities. More specifically, Chores are things we do in order to enable our Team to do work, or to improve the code base so that it can be worked with more easily, and so on. Here are some examples of Chores:
- ‘Improve the build script to incorporate module ABC,’
- ‘Re-arrange the Team room so that the testers and coders are sitting together,’
- ‘Add a new test box to the lab so that we can do dedicated performance testing,’
- ‘Refactor the FlightInfo module so that it’ll be easier to use,’ and
- ‘Have Joe spend some time coaching Diane and George on SQL.’
Another way to look at Chores is like this. The Team actually has two jobs: to produce Capabilities, and to maintain its Capacity to produce Capabilities. We can think of the Chores as work the Team does to maintain its Capacity, either by keeping the Code cleaner and easier to work with, or by improving the Team and its Environment.
Cite This Term
"Hardening Sprint" ScrumDictionary.com. Accessed Apr 18, 2024. https://scrumdictionary.com/term/hardening-sprint/.