Definition of Done (or not done)

As a developer and Scrum enthusiast, I am working daily on a self-organizing team. One of the parts of my daily agile work that I would give the most important is the principle of a "Definition of Done". I am currently reading a lot about agile development methods as well as design patterns and other architectural principles.

Why am I writing this article? Well, there are actually two reasons.

• I was reading a book and there were some thoughts about DoDs that I would not share and so I decided to write a post about my opinion about DoDs.
• Secondly, I was surprised when talking to some developers in an agile context (even Scrum) that they were not knowing what that is.

What is a "Definition of Done"?

Basically, a DoD defines whether a certain ticket, user story or task is done. The DoD should be defined by the whole agile team¹. Only defining those rules is not enough from my point of view. Actually, every team member should clearly understand the DoD and accept its content. Otherwise, there would be ignorance on that list. I do not think that it makes sense to have a DoD if you do not care about any quality assurance.

Visibility of the DoD

There are two things that I would like to say about how to present the DoD.

1. The DoD should be visible within the office to every team member. (e.g. whiteboard, large print, ...)
2. The DoD should be available and visible within Planning and Refinement meetings.

Content of a DoD

So now we are talking about what actually could be part of a DoD. All here listed elements are just proposals and contents that worked out for me in practical landscape.

Acceptance Criteria

Every DoD should contain that all acceptance criteria of a ticket are fulfilled.

Automated Testing

Every DoD should contain all needed test methods (e.g. unit, integration, acceptance, manual).

Internationalization

If you are doing i18n then I would make it part of the DoD to ensure that everything is automatically translated.

Review

All types of review should be done (e.g. functional review, code review).

DoDs and Refactoring

I read that the process of refactoring (especially in the context of TDD) should be part of your DoD. That is a point where I would fully disagree. As a developer, you could always optimize or clean up your code. I would rather than putting refactoring on the list, add the process of code review to the DoD. You ensure with that, that a certain code quality is reached, it is actually measurable and there is room for discussion.

End

So I hope I could show you what a DoD means to me and how you could use it. If you are already using it, I would be happy to see your version of DoDs.

Footnotes

¹ In Scrum context I would define the agile team as the team containing developers, designers (could be also counted as developers), product owner and Scrum master.