Get certified - Transform your world of work today

Do We Need a Hardening Sprint?

11/24/2014 by Ravishankar N

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.