Definition of Done (or not done)
Moritz Schramm Jun 14
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 team1. 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.
- The DoD should be visible within the office to every team member. (e.g. whiteboard, large print, ...)
- 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.
Every DoD should contain that all acceptance criteria of a ticket are fulfilled.
Every DoD should contain all needed test methods (e.g. unit, integration, acceptance, manual).
If you are doing i18n then I would make it part of the DoD to ensure that everything is automatically translated.
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.
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.
1 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.