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.

2. 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