Gallery
Object Oriented Analysis & Design with UML
Share
Explore
Gallery
Object Oriented Analysis & Design with UML
Learn Agile & Scrum

14-Create a Definition of Done

Create a Definition of Done

⁠
Loading…
⁠
⁠

Knowing When a User Story Is Complete

Have you ever been in the following situation? Your apartment needs a thorough cleaning, and you decide to be the one to do it. Your partner is ecstatic! Yet when they come home, rather than thanking you, they run a finger over a surface and show you the dust you missed. The place is cleaner - but in their eyes, the job is not complete.
The same thing can happen in software development! Different teams or team members can have other ideas of what it means for a piece of work (maybe a user story) to be "done" and potentially releasable.
The term "production" comes from manufacturing industries where a component or product would be ready for use when it becomes part of the "production line." When a feature is "ready for production," it means it can be pushed live where real customers will then see it.
Now imagine that you and your partner sit down and define what a full cleaning means! The checklist looks like this:
Sink empty
Dishwasher full
Vacuum all floors
Mop kitchen floor
Dust bookcase, fridge, and TV
Empty fridge and clean shelves
Clean inside fridge doors
With this list, you reduce the likelihood of one of you cleaning the apartment and the other disagreeing!

What Is a Definition of Done?

A definition of done (DoD) is a checklist of activities that add value to the product that must be complete before a team member can refer to a user story as "done."
⁠
image.png
⁠
⁠
A definition of done is a pre-release checklist
A DoD could be considered a “quality checklist.”
All of the automated tests for the user story run without failing.
The QA (quality assurance) team has tested this feature and has not found any defects.
The QA team has verified that all acceptance tests have passed.
The code was peer-reviewed (another tech team member looked at the code and was happy).
The product manager has tested and verified that they are happy.
The code quality score is at least 3.5 (assuming that some system calculates this score!).
There are no security issues.
All documentation has been updated.
Note: the above list is just an example. In a real-life scenario, you will define the elements in your "done checklist" depending on the tools and ways of measuring quality or task completion that have been incorporated.
⁠
image.jpeg
⁠
⁠
Let's write a definition of "done" that a team can use for user stories

How to Define Done?

The best way to create a definition of done is to sit together as a team and make a checklist that the whole team agrees upon.
Ask the questions, "What tasks would we always want to do?" and "What kind of checks would we always make?" before pushing code to customers ("pushing to production").
Consider any previous times that some team members referred to work as "done," but others felt it wasn't. What were the differences? Should those items be added to your definition of done?
If you have a quality assurance (QA) team that tests your products before release, what do they consider important?
Many teams write automated checks (or tests) on their codebase to know if some new code breaks any of the old code's logic. If you have automated tests that run on your codebase, you will probably want to include that "no new code breaks any old code." All tests should pass!
Do you have any automated systems that run on your code? Some tools like Code Climate can provide you with a quality score and can scan your code for bad practices, such as repeated chunks! If you have such tools, you can incorporate them into your definition of done.
⁠
image.png
⁠
⁠
A Code Climate report on a codebase (code quality is scored out of 4)

Benefits of Having a Definition of Done

There are many benefits to having a clear DoD:
A checklist ensures only high-quality work is released to users.
Team members will have much less reason to argue over what "done" means.
User stories typically get finished (i.e., "done") before more are started. This means fewer "works in progress" and more user stories are released to customers.
Measuring quality becomes part of the weekly/monthly routine.
Fewer items get "pushed back" into development because they only "make it out" of development when they are genuinely ready.
Fewer conversations like the one in the video below!
Agile Best Practices: The Definition of Done from 3Pillar Global [4:14 min]
Additional Resources Here's an explanation of
definition of done
⁠
by Dr. Ian Mitchell. He explains how it functions and also the reasoning behind it.

Let's Recap!

Writing user stories is a great way to create documentation that specifies the requirements of the business. Writing acceptance tests for each user story is an excellent way to define the scenarios that the logic of a user story must cover.
Acceptance tests are not the only thing that must be verified before a user story is pushed live. Rather, it is one fundamental part of what "done" means, and the team should define a full checklist of items that indicate when user stories are "done."
In this way, team communication, product quality, and user experience all improve.
Now that you know how to create a Definition of Done to move forward your stories, you have elements to start a Scrum project! But one thing is key: embark a team! Let's discover in the next chapter how you can get started with Scrum in your organization!
Gallery
Share
 
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.