TL;DR
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!
Long
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.
English
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.
A couple of posts on that:
http://www.developsense.com/blog/2010/09/done-the-relative-rule-and-the-unsettling-rule/
http://www.developsense.com/blog/2011/07/the-undefinition-of-done/
—Michael B.