Hardening sprint: Scrum anti-pattern or necessity?
Are hardening sprints a burdensome necessity or a Scrum anti-pattern? Let's explore how to make these iterations less exacting and how Agile organizations can avoid them altogether.
In the worlds of Agile and Scrum, there is no shortage of opinions about hardening sprints. There are evangelists, even zealots, on either side of the question of whether a hardening sprint is too costly or even necessary.
The term hardening sprint has been bandied about for more than a decade, with followers of scaled Agile frameworks often in favor of the concept. Those supporting an approach truer to the Agile Manifesto and Scrum Guide identify the hardening sprint -- and its conceptional companion, the stabilization sprint -- a Scrum anti-pattern because the practice goes against the very nature of Agile and Scrum.
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. The idea being: Teams push such work off so they can complete a sprint and move onto the next one, knowing they can circle back in a project-ending hardening sprint. The iteration is seen by some as purely for work the team has pushed off, one that produces no value-additive functions or features.
Let's explore why hardening sprints came about and whether the practice should be avoided.
Why hardening sprints exist
Hardening sprints are most common in larger organizations. When bigger IT organizations adopt a scaled Agile framework, the entities embrace multiple Scrum teams, each of which has eight to 10 members. Working simultaneously, these Scrum teams churn out chunks of releasable functionality sprint after sprint until the system is ready for a hardening or for developers to stabilize the software before its public release.
At one time, the Scaled Agile Framework (SAFe) called for a Hardening, Innovation and Planning (HIP) sprint at the end of what was called a potentially shippable increment. In SAFe's 5.1 Big Picture release in February 2021, the organization appeared to deemphasize the need for a hardening sprint in favor of more continuous development approaches that embody DevOps. While other scaled Agile frameworks or alternative Agile approaches may not call for using a true hardening sprint, they nonetheless advocate similar concepts, including:
- Large Scale Scrum (LeSS). This centers on sprints aimed at producing potentially shippable products that conform to a tight definition of done. If the definition of done is not met, the LeSS teams must decide how to proceed.
- The Project Management Institute's disciplined Agile (DA). DA enables teams to adopt whatever methods they deem best for them by borrowing concepts -- potentially including a hardening sprint -- from Scrum, Lean Agile, Kanban and other frameworks.
- DSDM. Formerly known as the dynamic system development method, DSDM builds on the rapid application development concept and is seen as more project management-centric, where decisions as to what to leave in or take out of a product are made as a firm project deadline approaches.
- Nexus. This basically layers an integration team on top of multiple Scrum teams to ensure integration happens throughout sprints rather than relying upon a hardening sprint at the end.
Why the definition of done matters
How an organization defines being done with a sprint determines the amount of leftover work that accrues for the hardening sprint, which, again, happens towards the end of a project.
More relaxed and flexible definitions of done exist for development teams that, say, declare victory on a story card within a sprint but risk minor or low-level defects popping up in production. There are more demanding and rigid definitions of done for teams that, for example, are confident that they've fully developed and tested all requirements on a story card -- and are certain that there's minimal risk that a defect reaches production.
In a development team's efforts to attain done, it is important to accumulate as little technical debt as possible. The more technical debt that bogs down an application, the more ballooned the backlog gets, and the more likely a hardening sprint (at minimum) is necessary.
The longer a development team fails to address technical debt, the more time it tends to take to identify and fix the underlying errors. When a developer needs to reacclimate themselves to an issue -- i.e., when they choose to deal with the issue in a hardening sprint as opposed to more immediately -- fixing the underlying cause requires more time. The extra time introduced by context switching is the interest that is due when paying down technical debt.
Large development teams have some leeway in how they define done. Small to medium-sized development teams don't have that luxury. Medium and small teams should do what they can to ensure story elements or full stories in a sprint are defined as done in a more rigid sense. The idea is to incentivize developers and testers to address issues when they first arise, especially if the incremental development and testing time does not endanger other stories in the sprint.
How to avoid hardening sprints
The examples below illustrate how smaller teams can avoid hardening sprints:
- Shrink the scope of user stories instead. Say a team has a story with a requirement that covers multiple conditions or scenarios. The team should prioritize the conditions and scenarios that are necessary for a minimally viable product. Via risk assessment, the team should identify the conditions and scenarios that are edge or corner test cases; i.e., test cases users are unlikely to encounter in the short term. Accordingly, the team should modify the story to cover only the requirements that its developers can develop and have QA tested within the sprint -- and have a new story cover the work that's to be carried over to the next iteration. Elements of DSDM use this approach.
- Spillover or off-cycle work. Sometimes a team will determine that it cannot complete the development and testing for all critical requirements of a story within a sprint's designated timebox. In this case, rather than defining done more rigidly, the team should continue but acknowledge that the work necessary is likely to spill over to the next sprint. Another option is to consider the remaining work for an off-cycle release to production if the team can complete the given tasks before the end of the next sprint.
Teams that know their sprint velocity can set aside a percentage of story points to accommodate for the spillover stories from one sprint to the next. Teams should plan to use this cushion first before they bring new stories into a sprint. This extra allowance enables teams to determine if it needs to groom its backlog to weed out the nice-to-have features and functions from a project -- and decide what should be pushed to future releases.
Also, teams that perform more unit testing and/or embrace test-driven development will gain a better sense of the number of conditions and scenarios it's possible to fully develop and test within a sprint.
Organizations should not be dogmatic and decide whether to embrace hardening sprints simply because of what some evangelist or zealot on the matter says. Instead, they should creatively tweak their existing Agile and Scrum processes to better suit their needs; by doing so, they may be able to avoid the debate over whether a hardening sprint has value or not. Organizations should always adopt processes that work best for them instead of trying to fit into the entirety of a particular framework.
