How to Know When Things Are Really Done

[article]
Summary:
Do you know when your work is done? Are you sure your feature is done? How about your release? Do you know when it’s done? Leyton Collins has some suggestions for you, your team, and your organization on how to know when things are really done.

How I wince whenever I hear a stakeholder say, “Oh, I thought you meant this …” or words to that effect. This is why it is so important within project planning for everyone to have a common understanding of the concept of what it means to be “done” and the concept of what it means to be a team. The piece of the puzzle that gets missed all too often is how integral these two concepts are to each other and to the success of your projects. Within these concepts are two key factors:

  1. First, everyone involved must know up front what is expected when one says, “I’m done.” For example, when team members are in a Scrum session and advising the rest of the team about the progress they’ve made on a task they’re accountable to complete, it’s important that everyone is on the same page about what “done” is. And that word "done" must also be relevant to everyone who needs to use it. The meaning must have a detailed context for product owners, developers, testers, document writers, and professional services people, including project managers in each of their roles. In my experience, it’s people missing that part that seems to get them in the most trouble overall.
  1. Second, think of “team” as an acronym for “Together, Everyone Achieves More.” No one can do it all on his own.

I recall a situation from my consulting days when something just seemed “off” in the first meeting on my first day there. It seemed everyone in the room had a slightly different interpretation of what the word “team” meant—so, I asked. As it turned out, that was indeed the case. The project manager meant the core project team: the people in the room. The product owner meant the core team plus the first and second tiers of stakeholders. The developers meant the development group, and everyone else was just “the project.” And it carried on like that. I encouraged everyone to appreciate what every great leader knows and breathes: “Diversity with some commonality creates greater strength”—synergy, if you will. And as they were all leaders in their own roles, they needed to leverage that synergy.

That situation is only one example of the importance of everyone having a clear understanding about what it means to be “done” and about the definition of a team. This is always one of the first concepts I impress upon teams and organizations whenever I’ve been asked to introduce agile and help them understand what it means to be agile. Then I quickly follow up with a statement that tends to bewilder most people at first: From my perspective, there are actually three definitions of “done” in any effort.

First, a bit of background.

The “definition of done” is defined at Scrum.org as a “shared understanding of what it means for work to be complete, to ensure transparency.” [1] It’s defined at AgileAlliance.org as "a list of criteria which must be met before a product increment (often a user story) is considered "done." [2] For me and for the teams I’ve mentored, having one definition of “done” is too light. This is because there is no such thing as “one size fits all.” No matter what a so-called standardization guru may tell you, this is just not the case.

Other organizations say each plan item should have its own “done” criteria. That would make my head spin on big projects and bigger programs and portfolios, and I suspect I’m not the only one. It’s just too excessive for everyone to keep straight without having to open some file to avoid people saying “Oh, I thought you meant…”

Now, on to the three definitions of “done.”

The reason I say there are three definitions is that there are three tiers of work:

  1. tasks for the individual team member (or members, if, for example, paired programming is part of your development practices) to do;
  2. stories for each functional group within the project team to do; and
  3. epics and themes that the project team agrees are a releasable unit to the business or customer.

No matter how new anyone is to projects, project management, or agile, three points are easy to remember. Thus, the three labels I use are:

  1. done;
  2. done–done; and
  3. done, done, and done.

User Comments

1 comment
Ed Kelly's picture

Having multiple levels of done is confusing and unnecessary.  I've read an article or two dismissing that concept.  First, at the task level. I've not encountered anyone trying to define done for a task.  A task should be small enough that it's done-ness should be self evident (coding, peer review code, unit test, etc.).  The first real level of done is at the user story level.  Ideally, it could be as simple as 1. All tasks are complete.  2. PO Accepts the User Story.  Rather than have an elaborate definition of done, include things like peer review code, unit testing, etc. as tasks in each story.  It's much less likely for "pieces" of done to fall through the cracks that way.  You may need a definition of done for a release too, but again it should be very simple.  I agree that "Done" should be understood identically by all stakeholders, but making that definition more complicated does nothing to ensure that.

April 10, 2014 - 2:11pm

About the author

Leyton Collins's picture Leyton Collins

A passionate Agilist with proven experience over almost 30 years creating and delivering innovations through proven and new business practices by leveraging great project teams to create greater products through synergy. My professional accreditations include PMP, PRINCE2, CSM, and ITIL. My key proficiencies reside in the areas of strategic planning, communicating 'the bigger picture' to technical hands on primes, and continuous process improvement initiatives. 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09