Definition of Done in a Scrum project

Definition of Done

In short, the definition of done is a comprehensive checklist of valuable activities required to produce software. The term itself is well summarized in an article by Dhaval Panchal.

As it’s pointed out, the DoD is never a one-size-fits-all set of rules, it heavily depends on the specifics of the project. Hence, it will (and should) differ in a quick and dirty Proof of Concept and in a complex, quality-critical system. It’s essentially experience and common sense which should be the determinants of a helpful DoD.

Why it matters

DoD aims at improving collaboration within the team. Therefore it’s important to be agreed on, especially during the norming stage of team development. People usually have different things in mind when saying “this task is done”. Often it has a fundamentally different meaning e.g. for a Product Owner and for a Junior Developer. Better speak the same language with all parties, just to avoid unnecessary misunderstandings. That’s where DoD comes in handy.

Real-life example

The following is an example of a definition of done agreement on a feature level in a medium-sized, Scrum-based, quality project. For convenience, it’s divided into three parts.

Before implementation
1. Make sure that User Stories are aligned to the INVEST rule and are estimated in Story Points. Both the Team and the Product Owner must have a common understanding of the requirements,
2. Check if there is any pending Code Review, if so – do that first,
Implementation
1. Put the ID of corresponding ticket in the commit messages,
2. Frequently comment on your progress and log time spent on the task in your ticket system,
3. Write unit-tests if applicable,
  1. Bugfixes: always unit-test the bugged path to avoid regression,
4. Align with the logging guidelines, so it’s easy to track problems in future,
5. Consider code static analysis feedback,
6. Update documentation,
7. Consider configuration, deployment and Continuous Integration adjustments,
8. Let your peers review your code,
9. If possible, let someone else write a User Acceptance Test for the new feature,
After implementation
1. Don’t merge your patch to the main branch, unless it’s green and you have 1h to react,
2. Let the CI server run all levels of tests & ensure they are all green,
3. If applicable – let someone else perform manual tests for your User Story
  1. Write down the testing steps and their results in the ticket, so that it’s easy to repeat the tests when needed,

The bottom line is

It should clearly communicated to all team members that any disobedience will be severely punished and no mercy whatsoever will be shown! ;-)

What’s the definition of done in your project? In what ways does it differ?

Like the article? Spread the news. Follow us on Twitter: @rspective & @pawelrychlik