Note: This article was initially published by the Scrum Alliance, here.
Every Scrum team worth its salt has a Definition of Done — it’s probably written down somewhere, and hopefully it’s displayed prominently in the team’s work space. Many teams look at the exercise of defining what “done” means as a one-time investment: Let’s figure out what “done” means for us and then let’s start, you know, actually doing stuff.
This one-time investment will yield some solid returns, both for the team and the business at large:
- Your product owner (any by extension, the business) will know what to expect when a story is done.
- The team will have a shared understanding of what it takes to complete something.
- Estimation (if you are doing estimation) becomes easier and more accurate.
- The team explicitly keeps a lid on technical debt, making future development efforts easier.
Defining “done” is often something that teams do at or near the beginning of their Agile journey. At this stage, many teams are still learning the practices of a given Agile framework. Their engineering practices may have not yet evolved to the point that they can really support agility. “Done” at this stage will be limited. After all, the team needs to have at least a reasonable level of confidence in their ability to achieve everything on the list, beginning with the next sprint.
And so, maybe “code is in production” isn’t currently doable for the team within a sprint. But surely, we wouldn’t call something done if it’s just sitting on some test server, right? I think it can be helpful for teams to call out these items. Have a section at the bottom of your Definition of Done for all the items your team aspires to be able to do within a sprint. Having it visible to everyone, all the time, will serve to remind your team that we’re not done defining what done means.
Simply reminding people isn’t enough though. The next question the team should be asking is, “Why can’t we do these things within a sprint?” This can be excellent fodder for the team’s retrospective. A “5 whys” exercise might even be a good approach for some of the larger issues. As impediments are identified and removed, yourachievable Definition of Done grows, and teams become empowered to actually deliver value in every sprint. You might even see an uptick in predictability, since there will be less carryover work sprint to sprint.
Having an aspirational Definition of Done could be a great way to keep important impediments top of mind for everyone on the team. How do you motivate your teams to continuously push the envelope with their Definition of Done?