Imagine you are doing major renovation on your house, like you are adding an additional level and you hired a team of top-notch contractors to do the renovation. Two months into the process, a representative of contractors informs you that they have completed all the work and they are done now. How do you determine if the work is completed? You will go and check out that second floor, you make sure they built it based on the agreed upon layout, there is running water and working electricity etc. Basically your verify their claims by going through a checklist to make sure completed work is to your satisfaction before you pay the contractors.
Definition of Done does the same thing. It is a check list of all the items to be checked off before your team declares the story is completed. Unlike “Acceptance Criteria” that is specific per story and describes what the ask is, Definition of Done (or DoD for short) establishes what must be true of each product backlog item for that item to be done.
DoD is partly done by your development team because it is their job to write high-quality, high-value software. So it is on developers and testers to define what quality is but you as Product Owner can add other criteria too. In the end both you and your team should agree on the Definition of Done before you start the first sprint. Let me explain this a bit more by showing you what my team Definition of Done is:
Each item in our backlog will be “Done” when….
- Acceptance criteria & functional testing is met.
- Code is peer reviewed by another developer and meets development standard.
- Unit tests written and passed.
- There are no critical or high bugs open.
- English & French content written and validated.
- Feature is tested across supported platforms & browsers as per the Official Canada Post browser support.
- Feature is tested for Accessibility; Web Content Accessibility Guideline (WCAG2.0) targets level A, AA.
- Feature with new UI elements is tagged for analytic.
- Remaining hours for task set to zero and task closed in Jira.
As you can see in example above the first four items define quality baseline of the code. However other criteria such as accessibility, dual language or administrative tasks in Jira speak to other aspects of being “done”. Definition of Done is a living document which means that you have to keep revisiting it to refine the “done” criteria to make sure they are still up-to-date and relevant to your stories and products. For my team during every sprint planning we quickly visit the DoD to make sure if it needs further tweaking.
After using DoD from stories for a while now I have extended them to software releases as well. I find having a release DoD where I have a checklist of all the things to be done prior to release extremely helpful. This helps my team not to miss any big ticket item. Here is DoD prior to every release:
And finally one last check list that is very powerful is to have Definition of Ready for each story. Definition of Ready verifies all pre-requisit work is completed before a story is ready to be pulled into a sprint. For example you have a story that lets user to to a date range and export some data based that time frame. This story needs a UX pattern, visual design for date selector and copy associated with the exporting function before it can be passed on to developers. You can create a Definition of Ready checklist so that a new story will NOT be pulled into the next sprint unless all the UX, content and VD sub-tasks are defined and completed. I find this is as a great approach to take the risk dependent external work out of your sprint.
Hope you enjoy these checklists as much as I do 🙂