Done is not just a document

[sebastian_solidwork (Sebastian Stautz)]

I ranted about Scrum’s Definition of Done: Done is not just a document

tl;dr: ‘done’ is (should be treated as) a adjective, not (as) a noun. People agree what is done. Any document is just a tool for that.

What are your insights and problems with the Definition of Done?

[ipstefan (Stefan Papusoi)]

Done can mean different things for different people, at different times, just like quality.
I’d think of it like this: what does ‘done’ mean and when does anyone apply it?
Rarely the entire company is agile. There might be different agile models or interpretations. So ‘done’ can be interpreted differently.

When a description doesn’t fit someone at some time:

• they ask for it to be changed;
• they ignore it;
• they do things hidden either alone or with a few allies;
• they make exceptions(just this time);
• they add specificities(only for, only in case of, when, …)
• when things go wrong anywhere, more rules that might fix the problem are added
• when things go well, regardless of what random ‘done’ approach is applied, no one remembers about it(months later someone asks, did we have a dod?)
• when too many rules slow down the process, formal description items get removed to lighten the process;
• when faster releases are wanted, at least half of it doesn’t apply and/or is ignored;
• if it doesn’t look good to some manager, some change can be forced;
• if a manager wants something unrelated to the ‘done’, he can ask for it to be there to be applied by the team;

The places that I’ve seen where a DOD worked better is where the people communicated openly and agreed with each other and didn’t formally describe anything, in contrast with the places where some were feeling forced into doing something by a bunch of other people in a formal way - revised each several weeks.

It’s good to discuss as a team from time to time and agree on adaptations when to broadly agree on something to be done.

And thinking of it from a tester’s perspective I don’t think it’s a good idea to get too involved in owning this from a quality point of view. It’s extremely dangerous.

[conrad.braam (conrad)]

Done = my team is unaware of additional work that my team can do medium term, to make this deliverable any sweeter than it is.

[sebastian_solidwork (Sebastian Stautz)]

@ipstefan

And thinking of it from a tester’s perspective I don’t think it’s a good idea to get too involved in owning this from a quality point of view. It’s extremely dangerous.

I agree with your post and don’t get this part.
You mean testers should not insistence too much that bugs gets fixed?

Instead of the typical “all tests are green/passed” I brought this into ours:
“current test coverage and results are accepted”

[mikeharris]

I have worked with a number of teams that have created Definitions of Done and wrote this about my experiences: Three short stories about the Definition of Done – TestAndAnalysis

[hananurrehman]

My definition:
Done: Until it’s a reasonable solution to a user problem.

My team’s definition:
Done: Depends on how much time we have left?

[mikeharris]

A Definition of Done is a checklist. I recently read The Checklist Manifesto and would recommend reading it because it gives so many insights into checklists: A review of ”The Checklist Manifesto How to Get Things Right” by Atul Gawande – TestAndAnalysis

[ipstefan (Stefan Papusoi)]

@sebastian_solidwork

I agree with your post and don’t get this part.
You mean testers should not insistence too much that bugs gets fixed?

What I meant was that I don’t recommend that a tester be:

• a gatekeeper for when a backlog item is done;
• be the owner of the definition of done and its enforcer;
• be the decider of what gets released;
• be the owner of the quality of a product(which is sometimes mentioned in the DoD);

[anders62 (Anders Wallin)]

I was very impressed with “done” as a young engineer back in the early 90’s. Project leaders made every project being the one crucial for the organization. Worked endless hours and took stress medicines.

100+ projects later my knowledge is deeper. The customer awaits more than stuff on time and that’s a win-win. Constantly and stress-free providence, starting from day 1 of the project and into the years after the delivery is what makes you and the customer happy. Done is not really all that significant. A process ongoing is what I prefer, and what keeps my customers satisfied.

The same with the carpenter I use for renovations of my house. There are always stuff to do, and I call him, knowing he will produce good work for reasonable money. And you want to be that kind of guy too.

[conrad.braam (conrad)]

Every managers nightmare, embrace the fire