We’ll Finish That Later

You have a done product increment that you could potentially release, but it requires some manual intervention to release it into production. The remaining undone work will perhaps take another day or two or three to complete.

This situation often leads to teams doing the remaining work at the end of the sprint or creating a sprint specifically for completing that work. When that happens, feedback loops and cycles get way too large. You can’t release this untested, unchecked software to production. Without a release, you aren’t getting feedback, which means you can’t validate the value of your product. Similarly, the further you move away from the partially completed work, the harder it is to switch contexts, hop back into the work, and finish it.

This distance between “done’’ and released to customers is a measure of agility. The greater the distance, the lower your ability to respond to opportunities in the market and to changing conditions that you could capitalize on. The greater this distance is, the higher your overall risk.

Some teams address this with specialized sprints that focus on a particular aspect of product development such as testing, requirements gathering, or designing. But specialized sprints aren’t a part of Scrum. We dive deep into these anti-patterns in Chapter 9, ​Thinking in Sprints​.

A common specialized sprint is the hardening sprint, where Scrum teams work on things like integration testing, performance tuning, security reviews, and localization. Often, this type of sprint becomes a catch-all for new features, sloppy code, bug fixes, and other work that signals poor craftsmanship. Hardening sprints, simply put, are an excuse to delay quality and we recommend never using them. Be on alert for these reasons teams often give for wanting a hardening sprint:

• We ran out of time and didn’t fully test this feature. We’ll finish testing during the hardening sprint.

• User documentation didn’t quite get done for this feature. I’ll finish that up during the hardening sprint.

• No need to engage support or security or infrastructure now—we’ll bring them up to speed during the hardening sprint.

• We’ll wait to write unit tests for this during the hardening sprint.

If you’re currently using a hardening sprint, it’s time to stop and address the reasons why the team can’t build a potentially releasable increment by the end of a sprint. Teams that are new to Scrum often don’t have all the practices and processes in place that they need to release to production in a repeatable and reliable way. And that’s okay. However, these are impediments that a development team needs to address.

Continuous integration, test automation, and strong DevOps practices take time to build and implement, along with a lot of money and often new skill sets. If you’re in the early stages of a Scrum adoption, your team may find hardening sprints tempting because you might not have some or all of these practices in place. Resist the urge to use hardening sprints and instead take productive steps toward improving your practices to achieve “done” by the end of a sprint.