Get certified - Transform your world of work today


Do We Need a Hardening Sprint?

24 November 2014

While executing Agile projects, many Scrum teams use a "hardening sprint." Do they do so because of issues in the "regular" sprints, or do they plan for it as part of the release? Often teams realize a need for it when the release date approaches. This article maintains that a hardening sprint is not a good idea and highlights why.

What is a hardening sprint?

A hardening sprint is an additional sprint that some Scrum teams run at the completion of all the regular sprints. They are planned for developing functionality based on the product backlog. While the hardening sprint usually focuses on final integration before the release, teams often use it to tie up the loose ends identified during earlier sprints, such as data issues or defects related to external interfaces.

Why do Scrum teams use a hardening sprint?

Most teams face the need for a hardening sprint when they near the release. They find that integration issues were not addressed in the earlier sprints, or the relevant data could not be used for testing. These issues force teams to introduce an additional sprint, and often the teams negotiate with the stakeholders for the additional time and effort.

However, there are also cases in which a hardening sprint is planned in advance based on the development cadence, the lead time of the operations team to provide infrastructure, and other such considerations. In these cases, the teams are not surprised toward the end of the planned releases.

Do we need a hardening sprint?

Hardening sprints are not a good idea. Viewed from the true spirit of Agile, a surprise additional sprint or a planned buffer sprint is not in alignment with Agile principles of timeboxed development to create a potentially shippable product. If the stories are correctly prioritized, the Definition of Done is unambiguous, and the product backlog is regularly groomed based on business priorities, the teams should be able to complete the development tasks -- including final integration -- within the planned sprints.

Continuous integration is an integral part of the Agile method. It is a useful tool for identifying build and integration issues early on and making relevant changes to the solution as the sprints progress. Today, easy-to-use automated integration tools are available. Teams that leverage these tools for their build and integration activities can plan their sprints to deliver committed functionality within the agreed-upon time lines and achieve quality and efficiency gains.

Even in a Scrum of Scrums scenario, daily or more frequent integration using automated tools should identify issues early on and help the teams proceed with their planned sprints. Automated integration tools offer the ability to bring the output of multiple sprints to the same platform and test the application components both individually and as a whole, single product.

Adopting DevOps practices such as continuous deployment makes the hardening sprint redundant. With automated builds and early involvement of the operations team, a near-production environment could be made available for testing and teams could uncover potential production issues up front to improve system behavior and overall application quality. With successful adoption of such practices, teams will be able to get the application ready for deployment whenever business wants.

Virtualization tools further eliminate the need to wait for real services to be made available for testing the application. These tools can be used as frequently as needed or in alignment with the build and integration cycle planned by the team.

While a hardening sprint is not a good idea, it is true that large applications will need comprehensive integration testing to revalidate functionality before moving to production. Here are a few tips to avoid the surprise additional sprint:
  • Along with functional stories, articulate all the nonfunctional requirements (NFRs) as well. Through the product owner, interact with other business stakeholders as necessary to extract information about NFRs.
  • Define "done" criteria for every story -- however small it might be. Include testing and integration as key items in the "done" criteria.
  • Involve the operations team -- the team(s) responsible for infrastructure, deployment, and production support -- up front, understand operational challenges, and get adequate infrastructure and support.
  • After the sprint review, address identified issues in the immediate next sprint. Resist the temptation to pile up issues and address them all in one shot in a "later" sprint. If this requires deprioritization of stories, discuss this with the product owner and get that agreement.
  • Groom the product backlog regularly to identify top-priority items and keep the build activities relevant to the expected functionality.
  • In a multi-Scrum team scenario, plan for frequent Scrum of Scrums meetings and validate functional and nonfunctional requirements. Adopt a collaborative approach to address integration issues rather than a we-versus-they approach with multiple Scrum teams.
  • If third-party components are required for integration, plan for them up front and include specific tasks in the backlog. Build and test the relevant interfacing functionality in the early sprints.
  • Seek support from the product owner and other business stakeholders for investment in tools for service virtualization and continuous delivery.
  • Effectively leverage the enterprise knowledge repository to mine for integration issues from past projects and plan to address the ones that are relevant to the application being developed.
Agile is about delivering useful functionality within a timeboxed iteration. Carefully selecting value-adding stories and leveraging continuous integration practices along with proven defect management techniques will help Scrum teams avoid an additional sprint -- either as a surprise or as part of a plan.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


SenthilVel Marimuthu CSM CSP SAFe-SPC, CSP,CSM, 11/27/2014 1:08:18 AM
Good Article on how Continuous Delivery through Agile Engineering practices can Eliminate hardening sprints....

Do you think , a Sprint 0(Zero) in the MIddle of a large complex release will he helpfull?

i mean, if there is Release planned for 2 sprints - and in the end of the 5th or th 6th sprint - the sprint 0 (Zero), can be a mechanism to evaluate the Half release or so ? thoughs on Sprint 0 in the mid...may be for 1 week....

SenthilVel Marimuthu
Ravishankar N, CSM, 11/28/2014 5:23:19 AM
Thanks SenthilVel for the comments.

I wouldn't suggest a mid-term Sprint 0. The review of the program and evaluation of the deliverables should be built in within the Sprints. This is to provide continuous visibility to the team and the other stakeholders. An interim review could just be a status update to the leadership but not something that would change course mid-way - because the direction setting happens in the beginning and any possible changes should be considered as the program moves along through the planned Sprints.
Santanu Bhattacharya, CSM,CSPO, 11/30/2014 12:53:05 AM
As I see typically hardening sprints are the sprints where the technical depts are clubbed together and corrected. That is a good practice as not always the complete technical debt reduction is not achieved as part of the sprint all the time because of several constraints including the maturity of the team, product owner, stakeholders as well as Scrum Master. In an ideal situation the hardening sprints shouldn't be required. However, depending on the maturity of all the above I recommend teams to take a week long hardening sprint (technical as well as functional debt reduction) every 6 to 8 weeks instead of keeping the hardening sprint to the end and delay the uncertainties and risks. We can call them regular sprints but the user stories would be mostly related to the business value obtained through debt reduction.

Depending on the teams maturity after a couple of times taking the hardening sprint through the inspect and adapt approach team may become mature and get rid of the need of a hardening sprint altogether. It's very context specific and depends on various factors.
SenthilVel Marimuthu CSM CSP SAFe-SPC, CSP,CSM, 11/30/2014 5:08:22 AM
Santanu: Thats the exact point which i asked with Ravi....As u Mentioned its a more of a context Specific....
Ravishankar N, CSM, 12/1/2014 1:52:04 AM
Thanks Shantanu for the comment. While practically it may be handy to have a hardening sprint, often it becomes a habit for the Scrum teams to bank on it for fixing issues at a later point in the delivery chain. As mentioned earlier regular product backlog grooming and a clear DoD should help the teams handle technical debt within the regular sprints. If the team is encouraged to introduce short hardening sprints in between, the expectation is there would be 'longer' hardening sprint at the end of the planned sprints. This is not a good practice as the fundamental principle of identifying issues earlier on in the life cycle is not used by the team to reduce rework and cost.
Robert Day, CSM, 12/1/2014 4:24:45 AM
There are other issues connected with product delivery that may well require writing into the product backlog. Although Agile development generally values product over documentation, there may often be a business need for documentation, either for the release to end users or to meet legal or regulatory requirements. If the team member charged with producing this documentation is part of the Agile team, then the final Sprint - the "hardening Sprint" if you will - may often be the best place to put that feature into the product backlog.

Otherwise, the product owner will have to factor that function into their post-development release programme (whether they use Agile for that phase or not). A failure to do this may often have implications further into the product life cycle, as issues arise when the product is released into the wider environment and either users encounter issues that need to be addressed or regulatory authorities begin to ask difficult questions.

Having a Sprint that is used for a range of "wash-up" jobs that fit nowhere else, don't contribute to the overall development of the product, but which are nonetheless considered important by the business, users or the wider community seems like a useful idea.

In other circumstances, it may be the case that a project is being delivered by contractors who have their own Sprint timetable. The end customer may well be in a situation where they cannot carry out acceptance testing on a Sprint's deliverables until they are deployed into a UAT environment that the end customer can access. This implies very much that the end customer's UAT will lag behind development by a Sprint. In the organisation where I work, we have done UAT testing on (for example) Sprint 8 during development Sprint 9, and fed back defects to the development team so bug fixes can be added to the product backlog and we can agree in which Sprint defects will be addressed according to their urgency.

It follows from this that some sort of "hardening" Sprint will be required to wash up any defects identified in UAT in the final "pure development" Sprint.

Your reasoning in not accepting the concept of the "hardening Sprint" is admirable in a situation where products are being rolled out to market with no specific end customer identified, or where enhancements are being rolled out to (say) an internal user used to working in a cycle of continuous improvement. But in a situation where there are multiple players, or a single project with a finite development period and a final deployment date after which the developers walk away from the product and do something else, the idea that a "hardening Sprint" is undesirable really doesn't survive first contact with reality.
Scott Duncan, CSM, 4/24/2015 5:32:19 AM
My reaction when I was first asked what I thought of a "hardening Sprint" was that it suggested what came before was "soft" in terms of its robustness hence incomplete in its Definition of Done somehow. I said that if what was meant by the term was a period of testing to cover things not easily (or even possibly) done during Sprints, then I preferred to call it an "integration" Sprint.

If the application is sufficiently large/complex with many teams contributing parts of it, then some sort of integration has to happen. If that can be done incrementally along the way then that would be ideal. But some things cannot be reliably verified piece by piece such as performance and security characteristics. (Well, pieces can but not so you can claim the whole system performs well or is secure until the whole system is together.)

What I have seen is an inability to get a build that allows integration level testing to happen much before all the software is done. Indeed, for larger organization moving from phased-sequential development to a more iterative and incremental approach, the inability to test frequently (and with good automation, especially for regression) is one of their greatest hurdles to becoming more agile.
Vincent Vollero, CSM, 8/28/2015 9:11:22 AM
Correct Scott! In an ideal situation the integration or hardening sprint should not be necessary, but few of us are in the ideal situation, especially when agile is new to an organization.

I am right now working with the team on a release plan for a project that is about to start, and we know for a fact that we will need this final integration sprint because this organization is fairly new to agile and scrum and we are surrounded on all sides by traditional waterfall non-agile thought and action. That is the reality of the situation and it would be unwise for us to not take this into consideration.
Shri Naveen Kumar, CSM, 3/17/2016 4:54:09 AM
Good article on hardening sprint.
I would suggest, in practical situations involving multiple teams, where each team is producing part or one module of the product, then need for the hardening sprint is justified as final integration validations and verifications done by operations teams exposes integration and performance related issues, which are possibly to happen to exposed now. In such a scenario we rarely left with choice but to have a hardening sprint.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.



Newsletter Sign-Up