After some feedback from the Done Fallacy post, I feel I need to explore done-ness a bit more.

How we work and talk make up some very interesting distinctions. For example, let’s think about what the word “done” really means. It sounds simple, but the meaning changes over time.

Let’s take a story, for starters.

When we start working on a story, we use “done” as an expectation matching tool. We define done-ness as an acceptance criteria in order to have mutual understanding of what we get in the end.

Done-ness includes these parameters:

• Functionality – What workflows we add or change (and which stay the same)
• Quality – How well will it work (and what won’t)
• Delivery format – How it will be released (and what following steps will be needed after it is “done”)

When we reach a discussion about the story, we’ve already constrained by time and complexity. The story was already cut down to fit in a sprint, or short enough to reduce risk. At this point, there’s a sort-of-defined picture of what the packaged story will include when it’s finished.

Now, what happens as we move forward in time? Things change, we learn as we work. When the sprint is over we can check the outcome.

This is where it gets tricky. Some aspects are easy to declare done/not done while others are a bit vague. Here are some examples:

• The story works in staging, but not in production. All we need is to deploy to production, which will happen when another team uploads. It’s “virtually done”.
• We discovered a few cases we didn’t think about originally. The story is either not complete, or is done for now.
• We implemented some of these cases we discovered, but haven’t tested them. While the original cases in the story work and deployed, we may need more work to complete testing.
• We implemented and unit tested, but a tester got pulled for very important business and managed to complete manual testing only, and didn’t write the end-to-end tests.
• We completed testing, but with few minor bugs we didn’t manage to fix.
• The story works, but we identified that for it to be more robust, we’ll need to redesign and redo it.

And there are many more examples. The story may be done, but it’s not really complete.

Now, if we talk about a feature, epic, saga, product or roadmap, things get murkier as we go up in scale. That means the done-ness in the beginning looks nothing like the done-ness in the end. Not only that, things are never complete.

Here’s the catch: It doesn’t matter.

Much like a comparing actual progress to an original plan, this is not valuable. We don’t learn much from comparing the story state now compared to the original done-ness expectation.

What is important, is what we have implemented and tested, andd is it good enough. If it is, great. If more work is required, that’s fine too – now we know better.

“Won’t it drop our velocity?”

Maybe. You can either:

• If the story is good enough – it deserves its points
• If it is not -it doesn’t
• If more work needs to be done – don’t give it points.

What you’re not going to do is spend 15-30 minutes discussing the level of done-ness. Talking about estimates being wrong is really waste. Just try to be consistent.

So, are we done here?