Definition of Done in Jira with Examples

The post was originally published on Smart Checklist for Jira blog

In every Scrum team, the Definition of Done and Acceptance Criteria (AC) checklists can be compared to a contract between the Product Owner and the dev team. They determine what the PO wants and what the team delivers.

According to Scrum Guide, a DoD is defined on a Company or Product level and all teams must follow it as minimum. But to make it all successful, it’s not enough to just write a definition down on a piece of paper. Each team member needs to know and understand what “Done” really means, both in terms of functionality and quality.

Yes, we know that it is easier said than done. That’s why we created Smart Checklist for Jira with custom list items to support your Definition of Done and Acceptance Criteria. With Smart Checklist, not only can you create checklists to keep your team updated, but you can also customize list items to your own needs, track project progress and see which tasks are really “done-done”.

In this article you will learn how to master creating a DoD and Acceptance Criteria list. But let’s start from a little bit of theory…

What is a Definition of Done: When is it Done-Done?

A Definition of Done is a pre-release checklist of activities which must be fully completed before the product is “releasable” and can be shipped to production. To put it simply, it is the answer to the question: “What does it take for a dev team to launch a product or a feature?”. Besides this, you may also want to ask your team the following questions when writing your own DoD:

Which tasks would we always have to do?

What needs to be checked before the code is pushed to production?

DoD Examples: One Type Doesn’t Fit All

Having a single type of a Definition of Done that will apply to every situation is impossible. A User Story, a Sprint, an Epic, or a Release each have their own unique DoD. Let’s take a look at some examples:

Definition of Done for a feature (User Story)

• Definition of Done for a sprint (all features in a given sprint)
• Definition of Done for an increment (a releasable version of a product)

USER STORY

Each User Story carries a set of Acceptance Criteria that, if met, define the US as ‘done’. In general, both the Definition of Done and the AC for User Stories have to be written before the actual development starts so that the team can capture all customer needs beforehand.

User Story DoD example:

• Unit tests do not find any bugs
• Code review has passed without issues
• Acceptance Criteria checkpoints are all met
• Functional tests have been completed successfully
• Non-functional tests have been completed successfully
• The Product Owner has accepted the User Story

SPRINT

On this level, we can check the greater part of our work, such as if all the implemented features fulfil their original assumptions.

Sprint DoD example:

• All User Stories are marked as “done”
• All tasks with the “To do” status have been finished
• All bugs have been fixed
• Unit tests do not find any bugs
• The backlog has been updated
• Successful performance tests
• The Product Owner has accepted the Sprint

RELEASE

Done on this level may refer to a collection of features that will satisfy a market need.

Release DoD example:

• Code is officially done and works
• All bugs have been fixed
• Unit tests do not find any bugs
• The Quality Assurance team has resolved all issues
• The documentation has been updated
• The build has been pushed to the staging environment
• All tasks with the “To do” status have been finished
• Every Acceptance Criteria checklist in each User Story is done

Best Practices of Definition of Done

Writing a DoD is just the beginning of a long process. Things get more complicated once the dev team starts working. Why? Because making sure that the “contract” (DoD and AC) between the PO and the team is respected isn’t an easy task. Here are a few tips on how to make it work:

1. Master Writing Checklists
The best way to make your Definition of Done easily accessible for everyone involved is to simply put it inside your Jira. The same goes for Acceptance Criteria. Once both are in your Jira, it’s all that much easier to keep things updated and organized across all issues.

2. Add the DoD as a checklist to all of your Jira issues
Once you have mastered writing checklists, it’s good to make creating them a habit and add them across all your issues.

Jira does not have its own built-in feature to track the Definition of Done. One the one hand, you can use separate sub-tasks for each issue. One other hand, you can add custom fields to hold this information. Some Jira users also recommend Confluence to keep a DoD for every user story. But using a whole different tool for something as simple as DoD checklist isn’t the perfect solution either. After all, it’s best to keep things under one roof, right? And luckily, we have a plugin for that.

With Smart Checklist for Jira, the checklist UI is automatically injected to all of your Jira issues. Once you install the plugin, simply go to any of your issues, and you will notice the Smart Checklist is already to the right side of the description. You can open it and start adding actionable checklist items. Here’s how:

Let’s say we want to describe a feature, its design and limitations. The feature we’re talking about is a search bar that allows users to quickly find hotels from the website’s homepage of a travel app.

In Jira, head to the right-hand panel to start creating your DoD and AC checklists right away. You can also use some of those best practices for writing checklists:

• Keep it achievable – to define what you want to deliver.
• Keep it measurable and not too broad – so that the dev team can plan and estimate the work.
• Avoid technical details – to keep things clear for everyone, in plain English. All in all, acceptance criteria should be expressed very clearly.
• Make the criteria testable – so that the QA team can verify that all criteria are met.

You can either add list items one by one or edit the entire list at once in a Fullscreen Editor. To edit the list, just click the Pen icon and you will enter the Fullscreen Editor. At the top of the screen, you will see Markdown guidelines. That’s where you can differentiate the status of each checklist item as follows:

• Header
• Todo
• Done
• In progress
• Cancelled or Skipped

Here’s a real-life Acceptance Criteria example of how you can edit your list. Once you’re done editing, click Save.

All it takes is just a few minutes to make your checklist look nice and clear as seen below.

But that’s not all when it comes to the editing options in Smart Checklist. Among others, you can keep the checklist to the right side or in the middle of the screen right below the task description.

You can also add details to each list item which is really great if you need to leave more information on how to do a specific task. In the Fullscreen Editor use the > symbol at the beginning of the row where you want to add more details.

If you’re working on a task with several teammates, Smart Checklist also makes it possible to highlight names and dates to draw everyone’s attention to these small but important details.

To highlight a teammate responsible for a specific item, put @ before their name.

Last but not least, if you like to stay on top of things, you can also configure a Smart Checklist to show the progress of each item on your Agile Board.

4.Less is More: Keep The Item List Short
To some it may seem tempting to include as many items in the DoD as possible to ensure the quality of the product. Well, obsessing over the list of criteria can be counter-productive. If a team has plenty of tasks to do and list items to tick off in a short time, they can either fail at completing all or focus only on doing part of it. That’s when the value of a DoD goes out the window.

5.Don’t Hoard it: Share your DoD
If the definition of done is merely a shared understanding and it’s not spelled out and displayed in a visible place, it will not be effective. This is because a good part of its value lies in being an explicit contract known to all members of the team. Ensure that it is easily accessible.

6.The Older, the Better: Manage the DoD as Time Goes by
A Definition of Done is not that kind of document that once written gets forgotten like a dusty book. It is a live document that should be reviewed regularly. In order to improve your DoD, you can disable or modify some of its issues. If you want to expand the list, we recommend making some issues mandatory and others optional not to overburden the dev team.

Photo by Clark Tibbs on Unsplash

#jira #fordevelopers #dod