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?
I think the definition of done is another child-like quality we’ve let develop, the childish desire for closure, and I think that it causes more harm than good.
Decomposistion and test-criteria are more interesting when they are on a gradient, like you suggest.
J
By my opionion you don’t need to add any explicit time for testing if you properly use story points and velocity – as this time will be included implicitely, because such time had been in included in the past (and done) reference stories as well.
Michael replies: I’m not sure I understand. Would it be the case that you don’t need any explicit time for programming, for example? What does it mean to “properly” use story points and velocity?
In our coaching we often sit with the team to write down their definition of UNdone: the list of things they still need to do between “Done” and “Release”. That works great as initial impediment list. After all, if it is not really done, there is no value.
Michael replies: Yes; this is very similar to my point of view on acceptance tests. Passing acceptance tests don’t mean that the product is acceptable, unless you’re whistling past the graveyard. Failing tests suggest that the product isn’t acceptable. The significance of passing and failing tests is asymmetrical.
Done means it’s running in production. Definition of done attempts to capture the different individual parts that are required to get there.
Michael replies: I could agree to that. I could agree to anyone’s notion of what “done” or “definition of done” means, in fact, but I’d have to acknowledge that the definition is to be applied, not followed, and that it’s specific in that context.
Wow. This is simple and to the point. I like it.
The definition of “DONE” is always a conundrum. Decomposition is key.
Maybe it needs to be changed to “Done… for now”. Seeing that you probably have completed the goals of the story, but you are usually not done testing it.
Michael replies: That’s why I’d suggest not only “done for now”, but also “done what?”
Maybe a really appropriate response to “done” is to ask “Huh? Really? So?” http://itknowledgeexchange.techtarget.com/software-quality/james-bach-on-critical-thinking-huh-really-so/
By the way of my mind “done” is a four letter word.
Michael replies: Yes, it is a four-letter word. What do you mean by that, though?
You’ve got it right. The central issue is that more than one person must perform work on the software component before it can truly be considered done. Finishing my work doesn’t make the software done. In fact, even after it is thoroughly tested, someone needs to integrate it into a final build and deploy it — and, of course, the end users need to check it out.
Michael replies: And even then it might not be done. After checking it out, the end users might reasonably require even more work to be done. We’re done when everyone (or the product, at least) is dead.
A checklist of to-do items works. Turn all the “to-do’s” into to-done’s” and you are finally finished!
Hmmm. When the “to-do’s” are “to-done’s” you might be finished. Yet it’s as you say above: done is always relative to some person, at some time, for some purpose, by some means of evaluation. You might think yourself done at one time or another, but someone else—or circumstances—might have a different point of view or new information for you. That’s the point of this blog post (http://www.developsense.com/blog/2010/09/done-the-relative-rule-and-the-unsettling-rule/), and it’s the point of the chapter on testing in Computer Programming Fundamentals.
When the checklist items aren’t complete, you can probably assume that you’re not done whatever it is that you’re evaluating. When the checklist items are complete, you face another evaluation step: is the checklist the only means by which you determine completeness? Might there be some terrible problem in the product that isn’t on the checklist? Is there any reason to believe that the checklist might be out of date or incomplete? That is, we can use any number of tools to help us to evaluate something, but I’d argue that the decision finally rests with human judgement.
[…] they describe. Today’s timely post comes from Michael Bolton on his DevelopSense blog. In “The Undefinition of Done”, Michael talks about the fact that people typically have different definitions: One issue, as […]
Here are some definitions or interpretations of “done”
1. We are done with “testing” for this release or cycle (a unilateral declaration)
2. We are done – we have hit a boundary of some resource – say time, budget or computing power.
3. Usage of done by testers imply fulfillment of a promise or commitment – problem starts if commitment is not clear, implicit and does not have a place in bigger picture that stakeholders see.
4. Done – has implicit connotation of sequential (akin to waterfall) nature of activities. we are done with this, “that” comes next.
5. When you hear someone saying “done” – you might ask “What part” and “how much” or “how much is yet to be done”?
Shrini
Hi Michael,
So simple and to the point, great post! There are a lot of words like done, which people listen to and hear different things from.
Communication as a whole is a troublesome subject, people often interpret different things from statements. That’s why projects with no feedback loops or customer involvement, can easily result in a unhappy recipient.
Nicely done, thanks for sharing.
Cheers,
Darren.
The following is based on what we are doing as a Scrum team, hopefully some of these ideas may help in getting everyone in the team on the same page for understanding “done”.
We have a “Definition of Done” written on a large A2 piece of paper and stuck onto the wall next to our printed out product backlog (visible to all inside and outside the Scrum team). The “Definition of Done” is a check list of items that needs to be completed for each User Story, it was created in a workshop by the Scrum team and it was reviewed & agreed to by the Product Owner (our Product Owner must confirm each User Story is completed at the sprint review. Also the “Definition of Done” is not User Story acceptance criteria). If the “Definition of Done” requires to change then the whole team must agree, followed by the Product Owner review & agreement.
Initially for two sprints the new Scrum team referred directly to the “Definition of Done” while doing sprint planning. By sprint three, the team understand what “done” looked like and good estimating of story points.
Each of our User Stories has a finial task “Check Definition of Done”; as a team each item on the “Definition of Done” is confirmed to be completed, if something has been missed, then a new task (which has not been often) is added, to ensure it will be completed.
The team has observed that some User Stories cannot always fulfil the “Definition of Done” due to items being unrelated, therefore common sense needs to be applied. e.g. A User Story that requires no code change can not fulfil the following item “Code Reviews must be completed”.
In conclusion the “Definition of Done” on the wall has helped our team.
Chris
Actually thinking about it, our title “Definition of Done” is still ambiguous without the context of the User Story.
Maybe it needs to change to “The User Story is Done” or “The Definition of Done for the User Story”.
Michael replies: Yes, that’s kind of the point of the original blog post, isn’t it? “Done” without context is like “good” or “expensive” or “jargon” without context. http://www.developsense.com/blog/2010/09/done-the-relative-rule-and-the-unsettling-rule/
Michael,
This is a concept that I’ve struggled with, working in the context of an Agile development process. My main concern is over the many subleties that can be masked by a status of “Done” on a piece of development such as a user story. Reporting in such binary terms may be simple for upper management to digest but experience tells me that, even small projects such as Agile sprints, things are rarely that simple.
To me a status of “Done” in relation to software testing is a misnomer. We are never done, we just stop. At my company I’ve tried adopting instead a process of reporting confidence on items delivered with explanatory reports around any areas where confidence is not quite what we would expect. Examples might include a high volume of issues encountered during testing, or certain areas of testing that we feel merit further attention than we’ve been able to achieve in that sprint. The aim of this is to place into the hands of the management the decision as to whether or not to commit more time to increasing our confidence levels in that area. This is by no means a perfect solution but I feel it does address the most fundamental shortcomings of the limitations of “Done”.
Thanks for raising this – certainly a great subject for discussion.
Adam.
Michael replies: Thanks, Adam. If you haven’t seen it already, don’t forget http://www.developsense.com/blog/2010/09/done-the-relative-rule-and-the-unsettling-rule/.
“Done” is a troublesome word – just like “tested”.
Implicitly they are troublesome because they are both past participles – which the reader/listener can interpret (without prior knowledge or guidance) as something that has been completed. So, the words themselves form a frame in the receiver. This inevitably makes it easier to fall into binary judgements.
Michael replies: I’d call them unitary judgements, in the senses that a) interpretations of what “done” means will be made by individuals, and b) each individual will tend to hold a single interpretation, rather than multiple possible interpretations.
Just as good testers don’t decide when something is finished testing, so a team working towards a “definition of done” wouldn’t necessarily decide when something is “done”.
Done (to me) implies the result of an assessment – this result, story, status was good enough – including how to handle remaining activities or issues raised.
An assessment, yes—but the one that matters is the person who has the political authority in a given transaction to determine what is “good enough”—or not good enough.
A good tester / team would provide a status with a story around the activities undertaken, not undertaken, not completed, not considered. The important aspects of this “not done” or “something that might affect the assessment of done” is what I think of as the silent evidence of testing.
Yes. In the Rapid Software Testing course, these days we say that testers must tell three parallel stories:
These are amonng the things that a manager needs to know in order to make an informed ship / no-ship decision. It’s also a way for testers to get out of the voting or “sign-off approval” business, which to me is either abdication or usurpation of the product owner’s role.
It’s quite common that a tester will find an issue outside what “might’ve” been thought to be the scope of the “definition of done” – this may or may not have direct relevance on the assessment of “done” – it may give areas for future or immediate attention.
“Tested” & “Done” will always be troublesome without any situational context or relation to what they mean. That’s where good testers can help light the way.
Hi Michael,
I see the problem your describing.
To my understanding it´s a matter of context:
– The programmer means “done” when he has commited and unit tested his code and the build is still green.
– For the tester it´s “done” after he has tested it.
– The PO sees it as “done” after a succeful demo meeting (or rollout to customers)
Regards,
Christian
Michael replies: Yes, a matter of context anda matter of timing. A programmer might have committed and unit tested his code, such that the build runs green, but might then realize a walloping bug as he’s refactoring a different module. A tester might have tested a product (and reported bugs); that same product may return to her a few days later with those bugs fixed. You yourself highlighted two contexts for the product owner. Here’s another: a key customer discovers a problem in a rolled-out product, and the product owner decides to re-open the product to develop, test, and ship a patch.
The point of Done, The Relative Rule, and the Unsettling Rule (http://www.developsense.com/blog/2010/09/done-the-relative-rule-and-the-unsettling-rule/) was to draw attention to the fact that “done” is subject to The Relative Rule.
In the team where I’m working now there’s no “done”, there are “code-complete” and “test-complete” (for this build)
I’m wondering whether this tuning on the term done has some negative impact on the velocity calculation and general on planning, since for planning we can only calculate with stories that are really done (also tested).
Michael replies: How do you know in advance of the decision when you are really going to be “done” or not? How can you know in advance of testing when you are really done or not? You might like to have a look at this blog post.
Of course you can differentiate some levels of done, however it should not have any influence on the planning.
I have the experience that stories marked as “done – ready for test” lose on relevance and tend to stay on the board till the very last day of the sprint, where some QA clerks starting test on it.
Nevertheless I see your point on the ambiguity of the term done, I’m just not sure that in this way we really solving the problem, or only alleviate the symptoms.
To solve the problem, it strikes me that a reasonable approach might be to begin to understand the nature of software development and of the way people actually think, speak, work, and decide. One meta-symptom of trouble, it seems to me, is that people ignore symptoms. Confusion of the definition of done is, to me, a symptom of confusion over the nature of the work. If people were to be more precise about what they were saying, there’s a chance that they could become more precise about how they’re observing and how they’re deciding. To me, that would be a good first step at solving the problem.
For example, you note a problem above: “that stories marked as “done – ready for test” lose on relevance and tend to stay on the board till the very last day of the sprint, where some QA clerks starting test on it”. What would happen if you paused for a moment and looked at the assumptions that underpin that observation. Here’s what I see: a) a story gets marked as “done – ready for test” (that is, it’s not done in any absolute sense; it’s ready to be tested, which means that no one is actually sure it’s done; b) when something gets marked as “done”, it loses relevance—that is, people stop thinking about it as important; c) it stays in that state until the very last day of the sprint—that is, while something else could be happening, the story simply sits there; d) people who test are called “quality assurance”, apparently, meaning that they are responsible for quality and others are not; e) people who test are clerks, and apparently not testers—and that testing is clerical work. I see a boatload of questionable assumptions there. You?
“I see a boatload of questionable assumptions there.”
So do I. I don’t mind that the way we work is correct. Not at all. I have a big problem too with this kind of separating the QA and the development.
Concerning “done” my point is that it’s ok to use some ‘ready’ terms in the life-cycle of a story, but you should not take such a story for velocity estimation (even if its code-complete or whatsoever). Although, when I think a bit further stories should have tasks not just for development but for testing and documentation too. The tasks are created to fulfill the definition of done, what means that if all the tasks are finished for a story, it becomes done (according to the definition, which is of course negotiable and should/could be discussed during the sprint as well).
Trackback:
http://www.thetestingplanet.com/2011/07/a-little-track-history-that-goes-a-long-way/
It’s all a matter of semantics.
When you say “definition of done”, you can come to an understanding with each other: you decide on /your/ definition of done: when this and that activity is finished, we are done for whatever we will deliver in this fixed period of time. As a team you come to this definition, which is the key word in this sense. This is most likely not the general accepted definition (as in the definition of anyone not in your team) of “done”
When you just say “done”, you have to cope with people’s own idea of just what “done” means. Usually this is something in the line of “no further activities required”.
So, when you know different people attach different meaning to the word “done”, I agree with you to just say what you actually mean, and think of how the person you’re communicating with can understand this.
Michael replies: I suspect that’s fairly clear to most people, but I think it’s important to point out something else: without testing, without experience with the product, we’re in a relatively weak position for anyone to know what “done” means. We can’t anticipate in advance all the things that are unlisted, unspecified, that haven’t been discusssed or described or predicted, that would cause us to say, “Oh-oh… not done.” It’s not simply a matter of declaring that “done” means “activities being finished”; indeed, that seems to me to be saying exactly the same thing with different words. It’s a question of new information arriving (as it pretty much always dones) that would cause us to revise our notion of what “done” or “finished” means long after we thought we had decided. Some people, I think, believe that shouldn’t happen. I would argue that such people are inviting the arrival of Black Swans.
I have a similar issue with using the word “transaction”. When I talk to automated testing specialists, “transaction” is just some point you measure the response time of. But, to a mainframe administrator, the “transaction” as the tester calls it, is actually resulting in several “transactions” on the mainframe as he/she defines it. And, to make it even more complex, when this an actions in, for example, an online banking application, the business will only call the actual transfer of money from one account to another a “transaction”. Here also, be aware of which definition is used by the one you’re communication with!
Sure; different words mean different things to different people. I’m saying something a little different: that the same word will mean something different to each person based on time and new information.
Thanks for writing that down a bit sharper. Even when people agree on what they understand with “done”, there should indeed be room for gradually growing insights. In that way people can agree on “OK, we have done what we initially intended to do (and agreed upon)” and still leave room to “but with this new unforeseen information the product is not ready to implement, so more action is required”.
So, yes, let’s be careful by using the word “done”, when other words can put it clearer without being ambiguous.
Hi Michael,
quite some response you got here, looks like it’s a hot topic in the scene…
I’d like to disagree with Simon Morley’s view, although he states in which he says “Done (to me) implies the result of an assessment…”
I’d like to propose that done often means “I’ve DONE my part, now it’s someone else’s problem.”
The mindset of passing the bucket to get the illusion that the problem has gone away to be dealt with other people seems to be a common problem. Of course the problem usually comes back – if a devloper passes the bucket the tester may find it and pass it back. If the tester passes the bucket it may come back via the customer and a support call.
As you note in the example with your article, the problem has not gone away although the human mind seems to be eager to say “It’s not my problem anymore.” What the subconcious should add is “At the moment.” or “For the time being.” But we seem to be very good and clubbing these thoughts into oblivion.
I like Chris Saunders approach of making the defintion of done for their project visible. That makes sure that we can’t get away with subconcious thoughts glossing over that we know deep down that we’re not yet done but only done some parts.
Interesting article and comments, thanks for making me think.
[…] The Undefinition of “Done” […]
Hi Michael,
In a testing sense, I have long hated this word, “Done”. In the environment in which I used to test, “Done” was not only an ambiguous term leading to miscommunication, but also a trap, designed to nail down testing into declaring the product “ready to ship”, “Gold”, etc. The implication was that if we said it was tested, they could finally get on with business with much eye-rolling and by the way, anything that cropped up after was usually the fault of QA for not finding it.
Michael replies: More language lessons seem in order. For some reason, people believe that “tested” means “all problems have been found”. Perhaps test framing and lessons in safety language are in order (that’s a blog post soon to come). I don’t know how to deal with the eye-rolling, other than to continue the conversation, to try to behave congruently (with my usual intermittent success) and to encourage others to do the same.
As the testing manager, I did everything I could to get my team out of the gatekeeper and perceived bottleneck role and into more of an “authoritative consultant” role. “What is the issue now?” is much better to work with than, “Are we done yet?”
As I’ve said before, the issue is not that testing is the bottleneck. The issue is that we don’t know what’s in the bottle. I encourage people to reflect on wow we got to that state of affairs?
Thanks for writing, Jason.
we’d have to change a lot of the things we say if we wanted to be accurate 100% of the time! we wouldn’t be able to say “break a leg”, “stop yanking my chain” or “we should get together sometime” 😉
Michael replies: Since being accurate 100% of the time is impossible so far as we know (Gödel proved that), I’d say it’s a foolish ambition in any case.
The first two examples you cite are idioms; the third might be an idiom, or a lie.
I think that as long as everybody knows what “done” means, it’s not really a problem…
Cool. I can accept that and simply blow the issue off… except, to clear things up, can you explain what “everybody” means? “Knows”? “Problem”? “Not really a problem”, as opposed to “not a problem”? It’s turtles all the way down.
A semantic note: it is notable that every agile team that uses “done” in their terminology also see the need to establish a definition of “done”. In contrast, those teams seldom need a definition of “testable” or a definition of “deployed” as those words carry enough meaning in their every-day-usage.
Michael replies: Are you sure about that? How would you know?
To me, the need for a “definition of done” says that “done” is so weakly defined (in every-day-usage) that we could actually have used any other (real or invented) word, and loaded it with a definition. Instead of saying “done” we could say “skribbished” and agreed on a “definition of skribbished”.
Using words with a more welldefined every-day-usage meaning like “tested” or “deployed” (in the way you indicate) seems much better to me.
Michael replies: I think it’s a trap to rely on “well-defined every day usage”. “Test” is a splendid example of a word that is overloaded like a New Delhi bus at rush hour. It’s unhelpful, I’d contend, to consider “well-defined every day usage” without considering whose definition, and the rest of the context in which a given word is used.
To make that more clear: I’m less advocating adopting or dumping particular words, amd I’m more advocating that we try to develop the kinds of culture that reflect consciously on what we mean, and learn to spot and deal with the traps appropriately for the context. Sometimes picking up or dropping a particular word is a shortcut that either triggers or signals that kind of culture, but I think there’s usually way more to solving the problem than that.
“Done” to me is:
Further effort, time, money, psychic energy is not worth the cost.
We all decide when we go home after a day at the office and in my experience, it’s based on the sentence above.
“Good enough” translation: “Good” = value “Enough” = stop (i.e. the price I am willing to pay right now).
Michael replies: Yes. Note that “value” and “enough” are decisions made in context by real people in real time. New information can always torpedo any prior notion of “done”.
Thanks for this. This page deserves a bit more than page 7 on a Google search. So I’m ‘bump’ing this with a reply.
Also, as SM I never just say ‘done’. I always counsel scrum teams to define done for EVERY context they have to deal with.
In my current role I’m in a huge F100 company with rigid rules for delivering software with several possible contexts to deal with. Is it company-wide service definition that has to propagate? Is it a desktop app? Is it a job to massage 17 million records for a particular purpose? Each one has a different notion of what done means.
What about plain ordinary code development? It is never just ‘code delivered’ so each code package may require several discreet steps that demand individual stories. Big Iron corporate systems often require discrete delivery steps over multiple sprints, each requiring their own story.
Anyway, done has to be defined for every context. This is a great discussion. Hope it gets bumped up.
Michael replies: Thanks for the comment. I’d like to emphasize that, as testers, we frequently find problems that suggest that the product isn’t done. It’s our job to look for such problems, so I’d suggest that our job is to test imaginatively and suspiciously to find the ways in which the product is not done, and the ways in which our notions of “done” are incomplete. In fact, I believe that defining things in terms of “done” puts the cart before the horse. In any definition of “done”, what we’re really talking about is a set of things that about which we could say “If these things aren’t done, then we’re definitely not done”; yet even when those things are done, the product could still have terrible problems. Reframing “definition of done” as “for sure NOT done as long as…” would help to keep us open to new information, I believe.
[…] alternating between small details and the big picture. We’re trying to figure out how our definition of done might be inadequate; how we might be fooling ourselves into believing we’re done when we’re not. […]