Why Should We Have ‘Definition of Done’ in Projects?

The importance of the ‘Definition of ‘Done’

People are different. They have different experiences and view software development projects and processes from different perspectives.

When a developer says that this or that feature is implemented, he often means that all the functions are implemented and are ready for optimization, refactoring, and extensive testing.

On the other hand, when a customer or a manager hears that the feature is implemented, he expects it to be ready for release.

Can you feel the difference? It’s almost as if developers are from Mars, and customers are from Venus (or vice versa). But they have to meet somewhere down the road.

This disparity results in having the feature which is half-tested, half-documented, half-optimized and eventually half-ready for the release.

That’s why an explicit and concrete definition of “done” is a small, but important checkpoint in software projects.

One Definition of Done states that the feature is done for release when it is ‘potentially shippable.’ That means that even if the project as a whole is not ready to be deployed to production, the pieces that are considered ‘done’ are in a good enough condition to be deployed.

Of course, this must be defined more precisely for each case individually.

The Definition of Done ensures that everyone on the team knows exactly what is expected as an end result. It ensures transparency and quality.

The perfect Definition of Done includes everything that the organization must do to deliver the ready product to their customers. The Definition of Done is an agreed list of criteria that the software must meet for each Product Backlog Item.

Achieving this level of completeness requires the Team to do a list of tasks. When all tasks are completed, the item is done.

Creating the Definition of Done

The initial Definition of Done must be agreed before the first Sprint.

The following steps should be taken to identify the Definition of Done:

1. Define the activities needed to deliver to end customers.
2. Decide which activities can be done during each Sprint.

Read also: The process of mobile app development explained

A sample of Definition of Done

1. The build is in a release-ready state and available for download.
2. The documentation is complete.
3. All the features not yet implemented or inactive are hidden from the user.
4. The source code is committed on the server.
5. The code has been reviewed.
6. Tests on devices/browsers listed in the project assumptions are passed.
7. QA (Quality Assurance) session is completed.
8. Issues detected during the QA session are resolved.
9. All blockers, criticals, and major bugs are fixed.
10. All acceptance criteria are met.
11. A manual has been reviewed and presented to the product owner.
12. The product owner has given his approval.
13. A potentially releasable build is available for download.

Here is a sample of the Definition of Done you can download and use for your project.

A well-prepared Definition of Done Checklist can make things easier and speed up the daily work of a software development team.

Precisely defined criteria which verify that the work was done help you avoid many conflicts arising from misunderstandings between team members and possible delays which may occur.

But be careful. A DoD Checklist that consists of too many details could lead to wasting too much time on unnecessary formalities.

We must also remember that this document is not a cure-all. It cannot replace good team communication as well as precise function requirements. But if it is a part of a well-functioning process, it could resolve many problems and help save some time for something more pleasant than overtime work.

l.sidorenko