The “Done” Fallacy

One of the earliest ideas you learn as an agile practitioner is “Done, Done, Done”. There’s a lot of thinking behind it, but for me it boils down to trust. When you don’t know what “done” means, the next person who gets you’re deliverable might be surprised.

As a rule, we don’t like surprises.

So regardless of when it’s going to be delivered, what the quality is or what it contains, it is better to achieve a mutual understanding of what “done” really means. If possible, prior to the delivery.

In agile teams, a “done” story is usually defined as a working work flow in the software. Mature teams put enough effort in the story to make sure it works – automated tests, code review, deployment automation – whatever is close to the team’s definition of “working software”.

If the team has all these in place, it seems that if we define all the stories up front, we’d actually know how much “done” we are in the feature, release or product level.

It’s never done until it’s good enough to ship

We don’t like big preparation upfront in agile, because things will change. The bigger they are, more changes will be introduced. It applies to requirements, design, architecture and plans.

If that’s true, then we can never really know how much on track we are. If the team is currently working on story number 25 out of the original 50 we came up with originally for the release, are we really half-way?

Things may change over the next couple of sprints – we may learn things that will drive us to drop or add stories, and maybe replace them with others.

In an exact point in time, we don’t really know how much done we are. And that applies at the feature, product and portfolio level. We can only decide if we’re ready to ship. If the feature, product or portfolio are ready for release. Someone, usually a PO or equivalent has to say – ok, this is good enough, ship it.

Even at the story level, we won’t always have time to code and test every path. So even a “done” story may not be really done, but still be good enough to ship.

That’s ok. Because regardless of level, from story to portfolio, getting to 100% done-ness is waste. We don’t need all the stories or features in there to ship. A good product owner knows when it’s good enough to ship.

A smart one will ship many times to get feedback and learn, understanding the product is never “done”.

We’re really never done. And that’s ok.

10 comments on “The “Done” Fallacy”

@halperinko - Kobi Halperin June 26, 2015 Reply

Thanks for an interesting article,
I see that from Testing point of view, in many cases a Story is ready – but we can test it only partially,
since underlying support is covered only in future stories.
So – can we call that story done?
Or shall we keep it hostage of another later story?
How do we track dependencies?
@halperinko – Kobi Halperin
@halperinko - Kobi Halperin June 26, 2015 Reply

BTW – is it me getting older, or the font you are using is too small ? 🙂
Gil Zilberfeld June 27, 2015 Reply

Thanks for the comment Kobi!
The done-ness is really an acceptance by the person who gets the software, usually a product person. He can take all the information – what was code, how it was tested, which cases are not covered, and even “it works, but further features will be much slower to build” and decide.

Done is in the eyes of the approver.

BTW – It’s not you, it’s me.
Carolina Gorosito June 28, 2015 Reply

Great article, Gil.
I see teams struggle every day to understand this concept. Done, good enough, complete? The difference seems just to be semantic , and represents a big challenge for decision makers.

Loved your conclusion: “Done is in the eyes of the approver.”

Thanks for sharing your thoughts!
Have a great done done weekend.
- Gil Zilberfeld June 29, 2015 Reply
  
  Thanks Carolina!
  I agree. Done seems to be the word of choice in agile, but it may mean different things to different stake holders.
  Might post on that too 🙂
Sebs June 29, 2015 Reply

done is shipped and measurably delivering value.

I find this a reasonable definition these days. This even points the discussion onto: “How do we measure this is delivering its value?” to the beginning of the story definition.

Props go to Unruly, @benjiweber and @pr0bablyfine.
- Gil Zilberfeld June 29, 2015 Reply
  
  Sebs,
  
  Thanks for the comment!
  While a “done” story, is indeed shipped and valuable, it may not or may not be finished. It may require more work still, and that’s what the post was going after. I think there’s a follow up coming 🙂
David Toon July 3, 2015 Reply

“Done” for a story is when the story is live… This could be either so you can make more money, save money or it is an experiment that you wish to learn from. In essence you are never done, as experiments are likely to fail and you should learn from these…

I find the woolly definition of “Done, Done, Done” just a cop out for multiple stages in the flow of work through the system. This is usually caused by silos between – Dev’s, Testers and Ops…

Do you not think that having some sense of closure is good? So you can celebrate successes and failures once something is live and making money?
- Gil Zilberfeld July 3, 2015 Reply
  
  The dichotomy of “Done” is the topic of a future post.
  I think closure is not a goal unto itself. I like the accomplishment, and I definitely like to release. But I’d rather release something that is good enough earlier, and not complete later.
Janet Gregory July 9, 2015 Reply

I really do hate the term done-done and decided to quit using it when I walking into a company who used the term done-done-done. It dilutes the purpose of the meaning done. I’ve started using and trying to get others to buy into the idea of being more accurate. Call it “story done”. Perhaps this means that all the testing we could complete in an iteration is finished. Define “feature done”. This might include other types of testing that didn’t make sense at the story level such as load testing. And then we have “release done” which might include testing we could get done before for some strange reason like interacting with outside software vendors….or something like that.
I don’t think we need we need to throw out the definition of done because it serves a very useful purpose. However, teams do need to understand what it means to them.