Mike Lyons explains definition of done: a team agreement on all steps required before work ships to customers. It applies across your backlog, not just one story. Examples include automated tests, product-owner review, no medium or high defects, and user testing. The team joke "are we done done?" shows what happens when your definition is incomplete.
When we think about delivering a smooth and continuous flow of value to our customers, one of the most important agreements that we can put in place is what a done piece of work looks like. What do we mean when we say we're done? Are we finished done? We often refer to that in the world of agile project management as a definition of done. So what is a definition of done? It's all of the different steps and characteristics that we need to finish before we can deliver a working product to the end customer. I remember working on an integrations team. We managed the Internal and external APIs for a product and there was a guy on the team, his name's Fred, and it seemed like every sprint we'd get to the end and we demo our work and then I would ask, are we done? And Fred would say, yeah, this is done. And then the product owner would say, did we update the external documentation? And Fred would say, well, we're not done done. We found out that done can be a deceptive concept. It taught us to think beyond the individual and beyond just like code complet or test complete, and to strive for a higher standard of done. After that, it became a bit of a joke on the team. Whenever we would approach the finish line of a deliverable, we didn't just ask if we were done, we would say, are we done done? Now, you might also be wondering, isn't this the same thing as acceptance criteria? You're likely familiar with user stories and part of that is acceptance criteria. Well, remember, acceptance criteria is specific to that piece of work, whereas definition of done will apply to all the work items across the backlog. If you're finding that you're writing the same AC across multiple stories, then you're likely looking at something that could be managed in the definition of done. Let's take a look at some examples. The acceptance criteria for the work item has been satisfied. Again, a head nod to your user stories here. Functionality has been reviewed by the product owner. Automated tests have been created for the new functionality. We don't have any medium or high severity defects that are outstanding. Code has been migrated to the staging environment. Now, you might notice here that I'm not saying it's been migrated to production. That could be your situation, and that's ideal if you can move your code all the way to the production environment. But I know from working with teams there's instances where that's just not possible. The important thing here is that we're all on the same page about what a done piece of work looks like for our team. Now, done isn't always a one size fits all situation. Sometimes we have different levels of done for different types of work. I was just describing an example of a user story, the smallest unit of value that each individual Agile team is delivering. But when we have an aggregate of user stories that comprise something like say a feature, and we're intending to release that feature to end users, well, there might be additional work needed to consider the feature as done. So our feature level definition of done could be things like functionality has been tested with a subset of real users performance metrics meet or exceed customer expectations in a production like environment updating user documentation. Perhaps there's training that needs to be done, maybe additional performance or security scans that we need to do. So consider that you might have different types of definitions of done depending on the level of work item that you're dealing with. So when creating your own definition of done, start with the basics that I've discussed here. Then add criteria specific to your product to your customers. Always ask yourself, if we meet all of these criteria, will our customers agree that we've delivered value? Finally, remember that your definition of done will evolve as you learn more about your customers and as your delivery process matures. So be sure to regularly review it and refine it with your team and stakeholders to ensure that it continues to serve its purpose. So think about your current team today. Do they have a well understood and highly visible definition of done? What level is it at? Does it include everything needed to consider the piece of work done? Do you need to ask are we done done?
