Understanding the definition of done.

definition of done

What is your definition of done? This is a question you often here in Agile software development. In this post I’ll take a closer look at what the question means, and why it’s so important.

Let’s backup, in Scrum the goal is to have potentially shippable product increments at the end of each sprint. “Potentially shippable” means the code is ready to deploy to production if needed. The code should provide some value to the customer or end-user.

The work within the sprint is broken down into user stories. Each story represents a feature or piece of functionality that provides value to the customer.  In order for user stories to be “done”, the following acceptance criteria should be met:

  • Code designed, built and unit tested
  • Code passed some forms of functional, integration, regression and acceptance testing

To speed up the process of “getting to done”, most software groups invest (or should) in automated deployments and automated testing.

But what if we have non development stories, how do we create a definition of done for those?

Some Scrum teams aren’t only delivering software. Here’s my take on defining done/acceptance criteria for non development user stories:

Always aim to have something tangible to show by the end of the sprint. Each story you work on should produce, or contribute to producing, a valuable output. It could be a document, spreadsheet or some other else. Whatever it is, it should be a tangible/completed item that item that provides value.

Remember, much of Agile is based on lean principles. In lean, anything you are working on that does not provide value to the customer is considered waste. The goal in lean systems is to cut waste, reduce constraints, and increase valuable throughput.

So when you are creating your definition of done, ask yourself these questions:

  • If it’s code related, what will it take to be production ready?
  • Whether its code related or not, what will it take to get it demo-ready? Is it tangible and will it provide value?
  • Does the team agree upon what it takes to be done?

What will happen if we don’t create a definition of done for our user stories?

Not having a definition of done for your user stories is a common problem. When this happens, teams usually pull more stories into the sprint than they can handle. They do this because they don’t realize what it takes to actually complete stories. The result is tons of work in progress with nothing getting completed. The more WIP you have, the less valuable output produced.

The increase of WIP is the most devastating effect of not creating a definition of done for your user stories. Nothing will slow down flow more than jamming the pipeline with user stories that don’t have clear acceptance criteria.

Next time you have a Sprint Planning meeting, review your stories to ensure the team knows the definition of done. Even if the team realizes they can only work on 1 story, if at the end of the sprint they have something completed that provides value to the customer, you’re on the right track!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.