Hardening sprint: why we did it, and why you shouldn’t

Tamás Szabó
Dec 12, 2018 · 5 min read
Photo by on

It was the end of January 2018, and our last sprint was devastating. We were working on a product that needed to go live at the end of the month, but the management changed its mind and rescheduled it to September. The software was ready, but the content for it was not enough, so they rearranged our whole Product Backlog.

The Development Team worked hard on finishing, but they couldn’t complete as much backlog items as they used to.

We compromised on quality, and as a result, technical debt emerged and our velocity went down. There weren’t as many smiles on our faces as before.

We violated the principles

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” —

“During the Sprint: Quality goals do not decrease” —

and it avenged itself: every team member was depressed and disappointed.

Lastly, here I was in the middle of it all, the Product Owner who needed to put away his own disappointment and handle the situation. So here goes the story what and why we (the Team, including myself) did.

First of all, we held an intense retrospective meeting to pinpoint how we got to the bottom of the pit. The main conclusions were:

  • the Product Owner should talk to the management to avoid these false deadlines;
  • the Team must never compromise on quality just to meet the expectations;
  • the Team should introduce the concept of CleanUp Stories to rethink former solutions after we gained more knowledge about the problems or the usage (and not as an “I owe you” note when delivering poor quality work);
  • the Development Team should reinforce the ;
  • the Team should hold a two weeks long hardening sprint to regenerate.

But what is a hardening sprint anyway?

“A hardening sprint is an additional sprint that some Scrum teams run at the completion of all the regular sprints. … 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.” —

We didn’t have known issues. We integrated everything continuously.

But we made everything in a rush and made poor design choices that couldn’t scale and made further improvement harder. We didn’t have acceptable test coverage so we couldn’t be sure that every single feature works flawlessly. Therefore we felt the need for a sprint where we could focus on these things.

My main aim was to get my high performing team back no matter the cost. And two weeks of work time of seven IT professionals is not something that you are willing to pay from your back pocket.

So I went and convinced the upper management to let us have a “sprint off”. It wasn’t easy but given the team members plan B to go on a holiday (“What?! They just got back from the Winter holidays!”), and the risk of maintaining software with questionable quality, they approved it. We agreed that it’s only a temporary solution, not something that they can count on when they face similar situations with tight deadlines. Pinky promise.

The hardening sprint went really well. The Team members, who didn’t feel the energy to work on new features, worked wholeheartedly on the CleanUp Stories and the integration tests. The number of lines of code dropped, test coverage went up, and all of our main code quality KPIs showed a much brighter picture. Everything went back to normal. Considering the alternative, when everyone goes on a holiday and comes back to work on the same mess, it was a real win.

But was it worth it? Not at all! We’ve spent a whole sprint on issues that wouldn’t exist if we had negotiated more about the features of the product to make time for better design.

Does any team member want to do again? Never again. Why? Because although it feels good to tidy up after a long time, what they really enjoy is to work on new things in an already tidy environment.

We learned a lot during that sprint, and the main lesson is to avoid the need for it.

Hardening sprint is bad practice, but it can be a painkiller. The best answer to a situation where everything already went wrong. So when the slightest idea of it comes to you or your customer, try to think about the reasons behind it, the alternative solutions you can come up with.

And in the meantime don’t forget the basics:

  • The Definition of “Done” (most of the time) shouldn’t be negotiable. For example: if it contains automated tests then you couldn’t leave them out. There’s a good reason why you put it in there before.
  • Integrate continuously, don’t leave it to the end of the project.
  • Don’t fill up the team’s capacity with only business stories, always save time for CleanUp Stories in the sprints. There shouldn’t be anything faulty at the time, but a cleaner environment lets you move faster in the long term.
  • Pay attention to your team in the retrospectives. At first, they just mention a fewer good thing. Then they start to complain about little things. Then they just want to get rid of the meeting, then get back to work quickly. They rarely see, let alone say, the main reason why they feel frustrated.

Did you like this article? Feel free to clap, comment, follow or share to let me know what you think.

Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!

We run a Serious Scrum channel on Slack. . Feel free to reach out and to share your thoughts.

Serious Scrum

Content by and for serious scrum practitioners.

Thanks to Willem-Jan Ageling and Sjoerd Nijland.

Tamás Szabó

Written by

Product/project person who is interested in making teams more efficient

Serious Scrum

Content by and for serious scrum practitioners.