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.

Done is ...

  • For tasks. It means I’ve completed everything I need to do that is part of my job description and that I’m empowered to complete. For example, in software development, this could mean:
  • The code is written, unit tested, and peer-reviewed and is ready for the build master, or uploaded to the automated build server to run that night, etc.
  • The functional testing is complete and regression tests or the test report now can be finished.

Done-done is ...

  • For major or significant deliverables. It means the functional unit (research and development, inside sales, marketing, professional services, etc.) has completed what they need to do and that deliverable is now ready for whomever needs to do their part with it next. It’s complete, but there’s still more work to do before it can be released for internal or external customer use. For example, the software build package successfully completed all required testing, and the remaining end-user documentation with GUI screenshots can now be produced.

Done, done, and done is ...

  • When the deliverable is now releasable or is released and ready for operational and customer use. It is the minimally viable or completed solution coming out of an interim sprint or the final sprint of the project.

For example, at a lot of companies, this is when the iteration, phase, cycle, or final sprint is successfully completed and the company now can begin to earn revenue by selling and deploying the product.

The great thing is that these three tiers of “done” apply to software and hardware development initiatives: IS, IT, and platform opportunities; process and other continuous improvement activities; construction of data centers; and anything that requires the efforts of more than one functional group member and that needs to be released to the business or customers.

In my mind, “done” mind is mostly about the task, story, business deliverable, or product being ready for transition to the next person, group, or stage. With that, I’ll leave you with a few final thoughts and guideposts.

We all know it’s about getting work done through other people, so depending on how clearly these tiers or definitions of “done” are defined, someone on the team eventually may still say something akin to “Oh, I thought you meant… ”

Combined with the definition of a project as a temporary and unique initiative, allowing some operations manager or group to standardize these definitions of “done” for all projects going forward more often than not just breeds more trouble—extrapolation between projects aside.

“One size fits all” does not exist. Expanding or reducing your definitions of “done” to three may help if you and your teams are struggling with handoff points, transition requirements or criteria for your projects and programs, or hearing team members and other stakeholders say, “Oh, I thought you (they) meant …” or words to that affect.

The effort required to create your project’s definitions of “done” will be a lot smaller if those definitions promote synergy and enable everybody involved to think of everyone contextually as “a team.”

And finally, saying “done,” “done-done,” and “done, done, and done” is fun—just as work should be.

References

[1] http://www.scrum.org/Resources/Scrum-Glossary

[2] http://guide.agilealliance.org/guide/sashimi.html

[3] Third reference for IBM developerWorks citation

User Comments

2 comments
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
Leyton Collins's picture

Hi Ed,

I only noticed your comment now so thank you (9 months later) for offering your experience here, and your perspective that these definitions over-complicate things. I'd actually like to see those articles you're referring to so please feel free to post them.

In contrast and in actual practice I've encountered many in several companies where this has the direct opposite affect to the concern you've raised; and for others I've offered it to.

It provides them with added clarity over the hand-off point from one team member to another. You haven't experienced? That's great, one day you may and in the interim that doesn't minimize what others need. Said, tongue in cheek, "stop shoulding all over other people".

Of course it's "much less likely for pieces of done to fall through the cracks" following a mature Agile approach. The challene is getting new teams to that level of process maturity. This is analagous to an over-protective parent telling their child not to go in the water until they know how to swim. Eventually You have to get wet if you're ever going to learn to swim. The same is true of waterfall teams transitioning to an agile approach. It's also analagous to throwing a team into the deep end of the pool. It may work, but based on a lot of research out there (e.g. CHAOS Reports from the Standish Group, PMI Journal articles, etc) it usually results in scummerfall implementations and sub-optimal efficiencies.

January 19, 2015 - 9:40am

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.