Photo by Anton Shuvalov on Unsplash

Understanding the Agile Definition of Done

The definition of done (DoD) is a critical concept for Agile projects. But I often see it misunderstood or just used loosely and interchangeably with project success criteria or acceptance criteria. So what is the definition of done exactly?

The definition of done is an agreed upon standard. The team and ultimately the Product Owner holds project deliverables against the DoD to determine completeness (also known as doneness).

Every deliverable is subject to the definition of done.

It is usually expressed as a checklist and should be very specific. Definition of done criteria typically require activities that will appear as tasks on a sprint or kanban board. The Product Owner (A Scrum Role similar to a product manager) stewards the definition of done. Decide on an initial definition of done before the project team starts sprinting, before working on the deliverables that create customer value.

Definition of Done is a measure of workflow progress

A waterfall project has a definition of done that is simple to understand. Waterfall moves the entire group of project requirements through a set of workflow stages. A software project starts with a requirements analysis, design, build, testing and transition to sustainment. The waterfall process is designed to achieve a fixed scope, budget and timeline.

Once the requirements have moved through the project phases, they are delivered to the customer all at once. This is known as a big bang release.

In the above diagram a simplified waterfall project is shown. The fifteen requirements for the project are determined at the beginning and the project attempts to keep change to the requirements minimized in order to protect the budget and timeline.

An agile project has different goals then a waterfall project and is not so concerned with locking in scope, budget and timeline. Agile understands that big bang is very risky because each requirements comes with assumptions that may be incorrect. Because of this agile attempts to push each requirement through all the project phases one requirement at a time.

What does this have to do with definition of done? So, pushing a requirement through design, build, test and transition to sustainment means getting that requirement to done. So the defintion of done here is

• Requirement defined
• Design decided and agreed upon
• Built to the design
• Tested to the defined requirement
• Functionality delivered to the customer for use

Evolving a Definition of Done

Getting a single requirement through the full workflow is very difficult. Especially for a new team doing agile for the first time. I suggest starting with a low bar definition of done. Too high of a standard can be deflating.

At this stage, what matters is that the Definition of Done has begun to crystallize.

— Ian Mitchell “Walking through definition of done”

A cross functional team is a key part of achieving your definition of done. If the team does not include, say testers, and you are expecting to hand the finished project over to testing in a waterfall way, then you can’t include Tested in your definition of done. You can however achieve Tested without testers, you just need to be a bit creative. Maybe other team members, like a business analyst, product owner or even a group of key customers can provide testing.

The definition of done should be examined throughout the project and part of the effort toward continuous improvement can be to focus on raising the bar on the definition of done.

There is no ‘Best Practice’ definition of done, every project determines what it considers done to mean. One of the Scrum principles is to deliver working software at the end of a sprint. This is a good principle to consider when defining done.

Homogeneous Deliverables

The more homogeneous you can make your deliverables, the more specific you can make your definition of done. A Product Backlog is generally made up of system features that increase what a user can do with the system. Everything that represents a feature will need to be designed, coded, code reviewed, checked in to source control, integrated with the system, deployed to test, tested, etc. The activities in this workflow should all be identified in the definition of done.

What about heterogeneous backlog items? In a project I am currently working on we have a backlog item to do a road show of the work we are doing. This work isn’t part of the core project deliverables but we have added it to backlog to track the work. This is a software project so the road show requirement doesn’t fit the definition of done. Our solution - we have exempted this item from the DoD.

Acceptance Criteria vs Definition of Done

Where definition of done is a standard applied to all stories and is defined at an abstract level. Acceptance criteria is specific to a single requirement (User Story). Acceptance Criteria is documented per story as part of Backlog Grooming. The Definition of done is documented at a project level. It would be redundant to add the definition of done to every story.

The Definition of Done should include completion of the acceptance criteria. A high quality User Story includes acceptance criteria which should be met before a story can be marked done. So completion of acceptance criteria is a great definition of done item.

You must meet all of the defined criteria or the user story isn’t done.

— Derek Huether “DEFINITION OF DONE”

A typical definition of done for a software project might be

• Code written on feature branch
• Code Reviewed and findings addressed
• Code Merged
• Code Deployed to Test
• Test Cases Executed
• All Acceptance Criteria met
• All Defects Resolved
• User Documentation updated and reviewed

Acceptance criteria that might appear on a story to add say add tag driven data filtering might be

• Tags can be added to items that allow tagging
• New tags can be added ad hoc but cannot be duplicates of existing tags
• When a tag is added to a list filter, then only the items with that tag are displayed
• When a list filter contains multiple tags, then items that contain at least one of those tags are displayed

You can see how test cases can be derived from the acceptance criteria, and also how meeting the acceptance criteria might be complete but the feature might not meet the definition if done. Perhaps the user documentation has not been updated, or the code review findings have not been addressed.

Summary

The Definition of done is a project level standard of completeness that applies to every item in the backlog. It is generic enough to be relevant to the project deliverables. I like to keep the Acceptance Criteria and the Definition of Done apart because they apply differently to the work and are consumed by different audiences.

Agree on your Definition of Done for the project as a team and make sure it is realistic before you start taking on deliverables. Start with a low bar and work your way up. Continuously push the bar higher by adding to and refining the definition of done.