Definition of Done: What Every Quality Leader Needs to Know

Definition of Done: What Every Quality Leader Needs to Know

One of the challenges we commonly face is the notion of “done”. Who defines done? When is a feature or sprint really done? How does Quality fit into ‘done’? Is the product complete when the deliverables are sent to the Product Owner? Does the Definition of Done include regression testing and/or automation components?

The Definition of Done (DoD) empowers your team to define what conditions must be met for something to be considered “done” and ready for the customer.

Let’s take a deeper dive into how we can better define when a product is done:

What is your Definition of Done?

Think of the entire project/product as its own ecosystem. There are many moving parts and each individual plays a vital, yet distinct role.

Establishing “done” throughout the product lifecycle, even before work begins, ensures each team member is aligned toward the same end goal.  Although responsibilities vary for each Scrum Team, all members will have a shared understanding of what it means for work to be complete in each phase:

• Early development
• Interval sprints
• Release level

Practical DoD examples 

To illustrate some variance in the definition of done, here are examples from two of my clients, both of which are committed to agile methodology.

Client A insisted that quality engineers be involved with all story grooming sessions. Each story had specific acceptance criteria that needed to be thoroughly tested and demoed to the product owner on behalf of the business. Upon sprint completion, each story was also considered and tagged for downstream regression testing and automation candidacy.  For this client, the Definition of Done included buy-in from the business as well as immediate regression testing consideration and a path to automation.

Another client I worked with considered the story “done” when the sprint was complete, and the QE’s tests of the story were passed.  Stories that didn’t make the cut off were rolled into the next sprint and the cycle began again.

For a little while, you may not notice much quality difference between these two models.  However, over time, we experienced some significant issues. First of all, when the business would get involved in the code, it became obvious that the development team was not thinking about the functionality the same way as the business user and rework was required.  And it’s so much harder to go back and rework stories from previous sprints!  Also, with no regression testing consideration given on the front end, the quality of the product slowly starts to slip and now you have the enormous task of building out an effective regression suite when it would have been so much easier to incrementally maintain the suite along the journey!

Definition of Done best practices

• Involve the business/Product Owner at the story level. It’s an investment to be sure, but having confidence going into business readiness testing or UAT is well worth it.
• Build in the testing next phases (like regression) of the testing into the sprint before closing and moving on. This is the best way to leverage the hard work that went into the sprint and have lasting impact.

How can defining 'done' help your company?

The DoD isn’t set in stone by any one group but rather by all groups – Product Owner, Development Team, Scrum Master, and Quality. If you would like to see some examples of the Definition of Done, or learn more, tapQA would love to help.

Josh Brenneman is the Delivery & Talent Director at tapQA. He has 10+ years of experience delivering value to organizations in the areas of strategic quality, delivery, release management, and testing.