Want to help editing a collaborative version of Definition Of Done checklist, driven by questions, rationales and “don’ts”?
Click here and feel free to share your ideas!
Some months ago my team and I had to define a Definition of Done for one of our projects.
Each item of DoD should be an activity useful to define when a feature is done-done.
In order to help us find the most proper items I proposed this pattern:
We should be able to summarize each item with a short question, like
Does it compile?
The question must be short and easy to remember, because we will be mentally or physically be asking it ourselves several times each sprint.
The whole team should agree on the detailed description of the fact we wish to assert, like “When we say the feature is done because it compiles we mean“:
Every single component compiles with no errors and produces artifacts
DoD is a contract between each team member. We must really agree with no ambiguity.
In order to ensure we all agree and understand the rationale of the rule, we can describe the anti-pattern behavior we want to avoid, like “<Done> must mean <It compiles> so that no one could say:”
It’s done, but …doh! I missed a semicolon. Just a second, please…“
So, we came with items like
|Question||Can it build?|
|Fact||There’s a build script and a Continuous Integration system able to deploy the project on a server and the script succedes deploying it on the stage server|
|So that no one could say||It’s done, but it runs on my computer only|
|Question||What’s the URL?|
|Fact||The Customer and the Product Owner can access and use the software from their computers|
|So that no one could say||It’s done but you must come to my computer to see it|
Shared with all
In order to collaboratively edit that document I prepared a google doc.
Then I shared it with my colleagues.
After few minutes I saw several unknown users lurking the document.
“Gosh!“, I thought, “This is a Company, reserved document! What’s happening?”
As a matter of fact, for a mistake I did share the document with a public Italian mailing list. My shame.
“Well, what’s the big deal?“, I started thinking. “Know what? A DoD is not that reserved, after all. On the contrary: we could learn so much, sharing ideas with other developers. Let’s see how other developers would define a DoD”
So I left it public.
Everyone was able to edit, refine, remove, add ideas.
Here is how the Definition of Definition of Done started.
Here I am proposing the same experiment, this time with an English DoD, possibly with a larger audience.
Please, don’t hesitate to edit, refine, remove, add or use ideas.
DoD is a team-specific issue!
One of the critics I suddenly received was about the fact that DoD should be built around the problems and goals a specific team has.
Yep. This is completely true.
The checklist I’m trying to collaboratively build is not meant to be an universal Definition of Done. I think such a list could hardly be conceived.
On the contrary, I aim to build a pretty complete, polyhedric, varied list of miscellaneous items for every team to select and use.