Quick Guide: Definition of Done User Story Checklist

Introduction

Definition of Done is a document that is the basis of work in Scrum team and in many cases it is enough to perform the optimal software development process.

But why we actually need the DoD Checklist?

That’s simple.

Every team member should understand, what really “Done” means. Because the work in Agile teams is based largely on mutual trust between team members. Everyone has to have the same definition of this word and can be sure (without additional verification), that when a specific area was marked as Done there is nothing, except the acceptation from the Product Owner side, what stopping us from deploy.

Checklists for User Stories and Sprints help us to stay productive. Each member needs to have great tools to boost team productivity.

Of course, even the best document is not a substitute for good communication within the team. However, we should use every possibility to make our process easier and more transparent, and the DoD Checklist is one of the best ways to do that.

Benefits of a user story and sprint checklist

• Process standardization and in the long-term better estimation of task duration
• An increase of software quality
• Less small fixes/bugs, because of well-tested features on each release
• Better team communication – Everybody has the same definition of done and process to follow

An example of DoD from Brainhub

When we decided to create the DoD in our company, we prepared together a short list of areas, that we should control, to deliver the highest possible quality software. We created two checklists, which help us in verification of our work on two stages of the software development process.

#1. Definition of done checklist for a user story

First and the most basic level is a single User Story, where we check compliance with the initial assumptions of a single backlog item, which were described in it.

On this stage, we also control the quality of written code and check if all necessary elements of our process were carried out (eg. QA session or tests in the test environment).

1. Produced code for presumed functionalities
2. Produced code for presumed functionalities
3. Assumptions of US met
4. Project builds without errors
5. Unit tests written and passing
6. Project deployed on the test environment identical to production platform
7. Tests on devices/browsers listed in the project assumptions passed
8. QA (Quality Assurance) session performed
9. Issues from QA session resolved
10. Refactoring completed
11. Any configuration or build changes documented
12. Documentation updated (if exists)
13. PCR (Peer Code Review) performed

Print your own FREE User Story Checklist here.

#2. Definition of done checklist for sprint

The second stage, which we decided to control is Sprint, where we check the greater part of our work. Here we can see if all the implemented features fulfill their original assumptions and if all the required conditions for the production deployment were met.

1. DoD of the USs met for each single US included in the Sprint
2. All ‘to do’ in the code completed
3. All unit tests passing
4. Product backlog updated
5. Project deployed on the test environment identical to production platform
6. Tests on devices/browsers listed in documentation passed
7. Tests of backward compatibility passed
8. The performance tests passed
9. All bugs fixed
10. Sprint marked as ready for the production deployment by the Product Owner

Print your own FREE Sprint Checklist here.

Conclusions

Well-prepared Definition of Done Checklist can make easier and speed up the daily work of a software development team. Precisely defined criteria of verifying the work was done, allow to avoid many conflicts arising from misunderstandings between team members and delays which may occur because of that.

However, be careful. Too detailed DoD Checklist could lead to wasting huge amounts of time on unnecessary formalities. We must also remember that this document is not a cure for all the problems.

It can replace neither good team communication nor precise function requirements. But if it is a part of a well-functioning process, it could resolve many of problems and help save some time for something pleasant than overtime.