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:
- 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.
- 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.”  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."  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:
- tasks for the individual team member (or members, if, for example, paired programming is part of your development practices) to do;
- stories for each functional group within the project team to do; and
- 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:
- done–done; and
- done, done, and done.