This blog isn’t “technically done” — it’s “done”!

There are likely as many definitions of “Done” as there are companies out there. You have to find the one that fits. And then stick with it.

This blog post isn’t “technically done”. It is done.

It’s not “done except for the review”.

It’s not “done, but I need to update a couple things”.

It’s not “done, but needs approval”. It is done.

You know how you know it’s done? Because you’re reading it. Because it’s been published and I’ve moved on to other work. Because my “write and post a blog” task has been marked off.

This post isn’t still being thought about, worked on, or anything else. It’s complete. Because for better or worse, I finished it, wrapped it up, put a bow on it and clicked “publish”.

Sure, I may need to go back at some later date and revise it. But that would be “new” work. This work, the work of writing and posting this blog, is unequivocally “Done”.

When it’s so easy to say when a blog post is done, why is our industry so wishy-washy when we talk about features, stories, and defects? You’d be amazed at the different ways people say a feature is done.

“It’s technically done, there’s just another review.”

“It’s done, but hasn’t been merged to the master branch.”

“It’s done, but hasn’t been merged to all the branches.”

“It’s done, but doesn’t have Product Owner sign-off.”

None of those are “Done”. They’re in different states of “In Progress”. Some are closer to “Done” than others. That’s fine. That’s why we often have fairly granular statuses. We should be adamant about calling it like it is.

So how do we decide when it’s “Done”? There’s a decent amount to unpack in that sentence. First, you have to define the “it”, and then you have to define “Done”.

Let’s start with the “it”. In simple terms, the “it” is whatever thing you’re working on, such as a feature, a story, a defect, tech debt etc. We usually track these in a tool such as Jira, Rally, Targetprocess, etc. The “it” is simply a work item in your tool. Really, the work item is just a representation of the real thing (the software product), but we need to get concrete here. So for the sake of this post, let’s call the “it” the artifact that exists in your tool.

Typically, the artifact will exist in a number of different states such as “New”; “In Progress”; “Done”. That’s an incredibly simple one (at Tasktop, however, we have upwards of eight states as we want to be very specific in our Feature Delivery process. That’s us though. You may be different!).

Each of these states needs to have really specific definitions around what they mean. This is where the “Definition of Done” comes into play.

You have to decide that for your organization. Write it down. Make everyone read and agree to it. You don’t move your story to “Done”, until it meets your definition. Your feature isn’t “Done” until, well, it’s “Done”.

Whether that means only the code has been committed, or whether that means a successful software build has been produced that includes the feature, or whether that means the Product Owner has reviewed and approved the functionality, it’s not “Done” until it’s “Done” by your definition.

You may even go so far as to decide that it’s not “Done” until the user docs have been updated. Or it may not be “Done” until Marketing has made a video for the feature. Or maybe it’s not “Done” until it’s been released to the public.

The point is that there are likely as many definitions of “Done” as there are companies out there. You have to find the one that fits. And then stick with it.

Now for the advanced stuff. Sometimes the “it” we were talking about exists in many tools at once. Or it appears in different forms in different tools. These multiple fragments of an artifact make traceability and product validation extremely challenging, as my colleague Brian Ashcraft expands on in his recent article in Dzone.

Here at Tasktop, our Field sends in feature requests via one tool. These requests are then flowed to the Product team’s tool to be turned into features, which are in turn sent to the Engineering team in yet another tool.

We automate this flow of work from tool to tool across the software delivery value stream, but I know there are some of you out there that do the exact same thing, but do it manually.

We’ve now entered the world of value streams.

Value streams are the manifestation of how information and work flows through your organization between teams and tools. It broadens the definition of the “it” and “Done” that we spoke of earlier.

Value streams are a bit outside the scope of this post. This post is about knowing precisely when you as an organization know when a work item is “Done”. It’s about being able to report “I am done with this and I’m ready to move to that.”

Now that I’ve written the post, had it reviewed and posted it, I can say with certainty…

I’m “Done” — can you?

Want to automatically flow information across your value stream? Request a dynamic personalized demo today.

Written by: Trevor Bruner

Originally published at www.tasktop.com on April 4, 2018.