The Undefinition of “Done”
July 13th, 2011
Recently a colleague noted that his Agile team was having trouble with the notion of done. “Sometimes it seems like the rest of the team doesn’t get it. The testers know that ‘done’ means tested. And if you ask the programmers, they’ll acknowledge that, yes, done means tested. Everyone is acting in good faith. But during the sprint planning meeting, we keep having to remind people to include time and effort for testing when they’re estimating story points. It never seems to stop.”
One issue, as I’ve pointed out before, is that people have preset notions about what “done” means to them. When I’m writing an article for publication, I put a bunch of effort into several drafts. When I’m finally happy with it, I declare that I’m done and submit it to the editors. I head downstairs and say to my wife, “Let’s watch The Daily Show. I’m done with that article.”
Of course, I’m not really done. The article goes through a round of technical editing, and a round of copy editing. Inevitably, someone finds problems that have escaped my notice. They send the article back (typically when I’m busy with something else, but that’s hardly their fault). I fix the problems. And I submit the article for publication. Then I’m done. Done-done. The article is ready for publication.
So it occurred to me that I could maybe avoid fooling myself. Instead of using an ambiguous word like “done”, maybe I could think in terms of “ready for publication”, or “edited”.
And that’s what I suggested to my colleague. “Instead of the question ‘When will this story be done?’ how about asking ‘When will this story be ready for testers to have at it?’ or ‘When will this story be tested?’ or how about ‘When will this story be ready to release?'” He thought that might be a useful reframe.
What do you think? If “done” is a troublesome concept, why not say what we really mean instead?
(No Ratings Yet)