Blog: Done, The Relative Rule, and The Unsettling Rule

The Agile community (to the degree that such a thing exists at all; it’s a little like talk about “the software industry”) appears to me to be really confused about what “done” means.

Whatever “done” means, it’s subject to the Relative Rule. I coined the Relative Rule, inspired by Jerry Weinberg‘s definition of quality (“quality is value to some person(s)”). The Relative Rule goes like this:

For any abstract X, X is X to some person, at some time.

For example, the idea of a “bug” is subject to the Relative Rule. A bug is not a thing that exists in the world; it doesn’t have a tangible form. A bug is a relationship between the product and some person. A bug is a threat to the value of the product to some person. The notion of a bug might be shared among many people, or it might be exclusive to some person.

Similarly: “done” is “done to some person(s), at some time,” and implicitly, “for some purpose“. To me, a tester’s job is to help people who matter—most importantly, the programmers and the product owner—make an informed decision about what constitutes “done” (and as I’ve said before, testers aren’t there to make that determination themselves). So testers, far from worrying about “done”, can begin to relax right away.

Let’s look at this in terms of a story.

A programmer takes on an assignment to code a particular function. She goes into cycles of test-driven development, writing a unit check, writing code to make the check pass, running a suite of prior unit checks and making sure that they all run green, and repeating the loop, adding more and more checks for that function as she goes. Meanwhile, the testers have, in consultation with the product owner, set up a suite of examples that demonstrate basic functionality, and they automate those examples as checks. The programmer decides that she’s done writing a particular function. She feels confident. She runs them against the examples. Two examples don’t work properly. Ooops, not done. Now she doesn’t feel so confident. She writes fixes. Now the examples all work, so now she’s done. That’s better.

A tester performs some exploratory tests that exercise that function, to see if it fulfills its explicit requirements. It does. Hey, the tester thinks, based on what I’ve seen so far, maybe we’re done programming… but we’re not done testing. Since no one—not testers, not programmers, not even requirements document writers; imagine!—is perfect, the tester performs other tests that explore the space of implicit requirements. The tester raises questions about the way the function might or might not work. The tester expands the possibilities of conditions and risks that might be relevant. Some of his questions raise new test ideas, and some of those tests raise new questions, and some of those questions reveal that certain implicit reqiurements haven’t been met. (The tester is done testing, for now, but no one is now sure that programming is done.) The programmer agrees that the tester has raised some significant issues. She’s mildly irritated that she didn’t think of some of these things on her own, and she’s annoyed that others are not explicit in the specs that were given to her. Still, she works on both sets of problems until they’re addressed too. (Done.) For two of the issues the tester has raised, the programmer disagrees that they’re really necessary (that is, things are done, according to the programmer). The tester tries to make sure that this isn’t personal, but remains concerned about the risks (things are not done, according to the tester). After a conversation, the programmer persuades the tester that these two issues aren’t problems (oh, done after all), and they both feel better. Just to be sure, though, the tester brings up the issues with the product owner. The product owner has some information about business risk that neither the tester nor the programmer had, and declares emphatically that the problem should be fixed (not done). The programmer is reasonably exasperated, because this seems like more work. Upon implementing one fix, the programmer has an epiphany; everything can be handled by a refactoring that simultaneously makes the code easier to understand AND addresses both problems AND takes much less time. She feels justifiably proud of herself. She writes a few more unit checks, refactors, and all the unit checks pass. (Done!) One of the checks of the automated examples doesn’t pass. (Damn; not done.) That’s frustrating. Another fix; the unit checks pass, the examples pass, the tester does more exploration and finds nothing more to be concerned about. Done! Both the programmer and the tester are happy, and the product owner is relieved and impressed.

Upon conversation with other programmers on the the project team, our programmer realizes that there are interactions between her function and other functions that mean she’s not done after all. That’s a little deflating. Back to the drawing board for a new build, followed by more testing. The tester feels a little pressured, because there’s lots of other work to do. Still, after a little investigation, things look good, so, okay, now done.

It’s getting to the end of the iteration. The programmers all declare themselves done. All of the unit checks are running green, and all of the ATDD checks are running green too. The whole team is ready to declare itself done. Well, done coding the new features, but there’s still a little uncertainty because there’s still a day left in which to test, and the testers are professionally uncertain. On the morning of the last day of the iteration, the programmers get into scoping out the horizon for the next iteration, while testers perform some final exploratory tests. They apply oracles that show the product isn’t consistent with a particular point in a Request-For-Comment that, alas, no one has noticed before. Aaargh! Not done. Now the team is nervous; people are starting to think that they might not be done what they committed to do. The programmers put in a quick fix and run some more checks (done). The testers raise more questions, perform more investigations, consider more possibilities, and find that more and more stopping heuristics apply (you’ll find a list of those here: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/). It’s 3:00pm. Okay, finally: done. Now everyone feels good. They set up the demo for the iteration.

The Customer (that is, the product owner) says “This is great. You’re done everything that I asked for in this iteration.” (Done! Yay!) “…except, we just heard from The Bank, and they’ve changed their specifications on how they handle this kind of transaction. So we’re done this iteration (that is, done now, for some purpose), but we’ve got a new high-priority backlog item for next Monday, which—and I’m sorry about this—means rolling back a lot of the work we’ve done on this feature (not done for some other purpose). And, programmers, the stuff you were anticipating for next week is going to be back-burnered for now.” Well, that’s a little deflating. But it’s only really deflating for the people who believe in the illusion that there’s a clear finish line for any kind of development work—a finish line that is algorithmic, instead of heuristic.

After many cycles like the above, eventually the programmers and the testers and the Customer all agree that the product is indeed ready for deployment. That agreement is nice, but in one sense, what the programmers and the testers think doesn’t matter. Shipping is a business decision, and not a technical one; it’s the product owner that makes the final decision. In another sense, though, the programmers and testers absolutely matter, in that a responsible and effective product owner must seriously consider all of the information available to him, weighing the business imperatives against technical concerns. Anyway, in this case, everything is lined up. The team is done! Everyone feels happy and proud.

The product gets deployed onto the bank’s system on a platform that doesn’t quite match the test environment, at volumes that exceed the test volumes. So the bank’s project manager isn’t happy (not done). The testers diligently test and find a way to reproduce the problem (they’re done, for now). The programmers don’t make any changes to the code, but find a way to change a configuration setting that works around the problem (so now they’re done). The testers show that the fix works in the test environments and at heavier loads(done). Upon evaluation of the original contract, recognition of the workaround, and after its own internal testing, the bank accepts the situation for now (done) but warns that it’s going to contest whether the contract has been fulfilled (not done). Some people are tense; others realize that business is business, and they don’t take it personally. After much negotiation, the managers from the bank and the development shop agree that the terms of the contract have been fulfilled (done), but that they’d really prefer a more elegant fix for which the bank will agree to pay (not done). And then the whole cycle continues. For years.

So, two things:

1) Defintions and decisions about “done” are always relative to some person, some purpose, and some time. Decisions about “done” are always laden with context. Not only technical considerations matter; business considerations matter too. Moreover, the process of deciding about doneness is not merely logical, but also highly social. Done is based not on What’s Right, but on Who Decides and For What Purpose and For Now. And as Jerry Weinberg points out, decisions about quality are political and emotional, but made by people who would like to appear rational. However, if you want to be politically, emotionally, and rationally comfortable, you might want to take a deep breath and learn to accept—with all of your intelligence, heart, and good will—not only the first point, but also the second…

2) “Done” is subject to another observation that Jerry often makes, and that I’ve named The Unsettling Rule:

Nothing is ever settled.

Update, 2013-10-16: If you’re still interested, check out the esteemed J.B. Rainsberger on A Better Path To the “Definition of Done”.

9 Responses to “Done, The Relative Rule, and The Unsettling Rule”

  1. I think I see this whole “Done” thing as much more clear-cut than you do.

    Michael’s reply: Oh, it’s not that I don’t see it as clear-cut. It’s that I don’t see it as clear-cut outside of a specific context. I think that most of the angst I see and hear has to do with the failure to recognize that.

    For me, “Done” applies at the story level, not at an effort level and not at a product level.

    Yes. Note that you’re specifying the to some person part (“For me), and the at some time part (“at the story level”), and that we’ll very shortly hear from you on the for some purpose part.

    At an effort level, “Done” doesn’t apply because (as you point out) it’s meaningless to say that we’re “Done” programming but “Not Done” testing (or any other arbitrary division of activities or labor). Declaring “Done” on any subset of activities associated with delivering a story is meaningless.

    I don’t think it’s helpful to say that it’s meaningless, since it’s certainly meaningful in relationship to something (some task or some object) and someone. My goal here is to encourage people to ask (and to state) what they mean when they use a word—like “done” or “agile”—that is packed with many possible interpretations.

    At a product or system level, “Done” doesn’t apply because (as your post shows) the only time we can be “Done” is when the last user logs out for the last time. Until then, someone somewhere will want something added, removed, or changed. Thus products are only “Done” when they’re well and truly dead. And systems that make it into production and serve stakeholders well usually live far longer than anyone expects.

    But at a story level, “Done” is straightforward: does the implementation of the story meet both the letter and spirit of the product owner’s expectations? To find out, we check it and explore it. We address shortcomings. When the product owner accepts it, that story is “Done.”

    I agree with that, with a caveat: “This is what Elisabeth (and the teams with whom she works, presumably) mean when they talk about a story being done.” And I would be able to agree with other uses of the word “done”, too, from other people and in other contexts. Not all of them will come so clearly stated in advance. Some will be applied by groups, and others by individuals. Some of them will be heuristic, without a clear decision rule (as in the heuristics for deciding when we’re done testing or exploring or (if we’re a product owner, when we should release the product). And all that’s okay, as long as people recognize the risk of misunderstanding, and manage that risk. But back to your definition of “Done”…

    The notion of “Done” then becomes a useful tool. It provides clarity and focus. It frees us to move on to the next story, and the next, without leaving loose ends to get tangled up in. It lets us measure how much we can do. And in doing so it gives us a sense of cadence and momentum in our work.

    Ah, there we are: “for some purpose.

    Thanks for writing, Elisabeth.

  2. Markus says:

    Hi Michael, I have a question regarding the following sentence: “Done is based not on What’s Right, but on Who Decides and For What Purpose and For Now.”

    I’m struggling with the word “Purpose” in here (probably due to English not being my mother tongue). For me purpose means a single idea on which the decision is made. However most of the time several factors influence such a decision.

    Michael replies: I don’t think you need to think of “purpose” in the singular. But even if you do, you can pack a bunch of factors into the decision. In the Black Box Software Testing course, for example, Cem Kaner contrasts a common definition of a computer program (“a set of instructions for a computer”) with one of his own: (“a communication among several humans and computers, separated over distance and time, that contains instructions for a computer”). He compares that common defintion with an idea about what a “house” is (“a set of building materials arranged in house design patterns”), and notes that he’d rather think of a house as “something for people to live in”. Well, there are lots of factors to living in a house, but they can be wrapped in that general statement of purpose.

    Following from this shouldn’t the definition rather be: Done is based not on What’s Right, but on Who Decides and Under Which Circumstances and For Now.

    Oh, yes; you can keep going a long way with refining any definition when it’s useful to do so—that is, when it addresses your purpose(s).

    One could also replace “For Now” with “Within A Given Timeframe” but that would probably need clairvoyance.

    “For Now” is a special case of “Within A Given Timeframe”.

    Markus

    Cheers. Thanks for writing.

  3. CB Anderson says:

    I understand that ‘done’ is a word completely loaded with subtlety, and as you point out – done is never done from all points of view. But I think the term ‘done’ (provided we can imagine it as nothing more than a word used to describe a particular point in software development) is still a very useful term.

    Michael replies: Yes. In fact, it’s so useful that millions of people use it in different contexts. Consequently, if you want to use it as a term (update: and as Michel Kraiij astutely points out just below, if you want someone else to understand what you mean by the term –MB) , you need to specify and to some degree constrain the context in which you use it.

    When the software leaves the team and is demonstrated to stakeholders, every member of that development team should be able to say with conviction that the software released is ‘done’.

    To my team, ‘done’ means that the software has passed acceptance and unit testing, has been deployed and has had significant exploratory testing. In essence we must all be able to say with conviction: ‘we have done the best job we could with the specification and resources we had.’

    As with Elisabeth’s comment, note that you’ve been specific about what you mean. That’s helpful to people who haven’t thought about it, and who might misunderstand or disagree. Here, you’ve managed the problem of ambiguity and misinterpretation. If someone disagrees, you can have a conversation about it. (Individuals and interactions, customer collaboration, responding to change, and all that.) And you can work it out.

    If the business moves the goalposts afterwards, well the software was still done – you can’t change that. But the features need to be done again, differently.

    Yes; the software was done to some person(s) at some time. And now it’s a different time.

    -Callum-

    Thanks for writing!

  4. Michael, great blogpost!

    A small suggestion to one of your answers:

    Yes. In fact, it’s so useful that millions of people use it in different contexts. Consequently, if you want to use it as a term, you need to specify and to some degree constrain the context in which you use it.

    May i suggest an alternative: “For someone else to be able to understand the term…”. I was missing the notion of understanding a term for communication.

    Michael replies: I don’t really need to present that alternative… because you’ve just done it perfectly. Thanks for the refinement.

    Next, I hope you don’t mind me barging in into the replies and asking a question to one of the respondants ;):

    I don’t mind at all.

    Elisabeth, You said: “When the product owner accepts it, that story is “Done.““. When does the product owner accept the story? In your context, is the actual usage of the solution in the production environment included in the subset of activities associated with delivering a story?

    I ‘live’ by the context-driven school principles. One of those principles is: “The product is a solution. If the problem isn’t solved, the product doesn’t work.” To me, without this step, a story is “Not Done”.

  5. Michel asked, “When does the product owner accept the story? In your context, is the actual usage of the solution in the production environment included in the subset of activities associated with delivering a story?”

    During the sprint. The teams I’ve worked with deployed to a production-like staging environment throughout the sprint, and the product owner accepted stories on an ongoing basis. We didn’t wait for a formal sprint demo since that would just delay the feedback.

    Michel said, ““The product is a solution. If the problem isn’t solved, the product doesn’t work.” To me, without this step, a story is “Not Done”.”

    The problem with that definition of Done is that we can’t declare Done until after it’s shipped and we see if the solution actually solved the problem in the real world. That’s too late.

    So I agree that if the problem isn’t solved, the product doesn’t work. But just because the whole problem isn’t solved (yet) doesn’t mean that a story isn’t Done.

    (I’ll note that the original question that sparked the whole discussion had to do with defining Done in an Agile context, and that’s the context I am speaking from. The stories I work with are very thin slices of capability, stuff that can be implemented in a couple days. Each story is so small that it usually doesn’t address an entire problem, it’s just a step in the solution.)

  6. [...] Development remains hard, though, because the problem space is vast. Dealing with that vastness really takes time, and there’s no substitute for that. Even experience doesn’t help. Also, see Michael Boulton and the Unsettling Rule. [...]

  7. [...] were looking for. The intent of this principle is good, but it needs enhancement on the concept of what working means in your context and to [...]

  8. Thank you a lot for such really valuable information found in the your blog.

  9. [...] This conversation is opposed to reviewing documents which have taken time to write & are invariably out of date as soon as they are published (subject to Michael Bolton’s Relative Rule?)* [...]

Leave a Reply