Definition of Done: A Powerful Technique to Align Project Expectations

My husband, a painter, tells me that the most difficult task of an artist is to know when your work is done. If you finish too early, it will be obvious that the piece is incomplete. But the temptation is equally great to overpaint, adding and adjusting to the work until the original vision is compromised under layers of unnecessary paint.

If you have followed Persimmon for any length of time, you know that we believe strongly that every team should understand “what success looks like” for their project, task, meeting, or role. But there is a second question—a kind of companion to the first—that is critical for teams struggling with the quality of delivery: “What does done look like?”

The first question (“What does success look like?”) lays out the result, or end-state, that you want to achieve. The second question (“What does done look like?”) defines specifically what must be in place for the team to put down their paintbrush and declare victory. It is more than a list of deliverables—it defines the level of completeness and quality that must be present by the end.

A great challenge for artists is knowing when to put their paintbrush down and consider the work finished.

All too often when I review project schedules, I’ll see generically named tasks or milestones; for example, “Complete Project Plan.” But what does it mean to “complete” the project plan? Does it mean:

• The Project Plan is drafted.
• The Project Plan is drafted and submitted to the approver(s).
• The Project Plan is approved.
• The Project Plan is approved and communicated to the team.
• The Project Plan is approved, communicated to the team, and publicly archived.
• The Project Plan is approved, communicated to the team, publicly archived, and a plan is in place to manage changes to the document going forward.

In our experience, when the “definition of done” is not clarified for a given task or deliverable, the team will insert their own assumptions about what it means to be finished—leading to increased misunderstandings, conflicts, and potential rework.

Definition of Done Technique

Like Leader’s Intent, the “definition of done” technique can be formal or informal. There is a lot of value in writing a formal definition of done for a project, or even each high-level deliverable. Documenting the “definition of done” ensures it serves as a reference later and can be a critical exercise for capturing and communicating the team’s assumptions.

On the other hand, training your team to informally ask “what does done look like?” for a given task or objective is also a powerful way to align expectations continuously, especially within a rapidly changing project environment.

Here is an example of a formal, written “definition of done” at the project level.

• “Our twelve new Preventative Maintenance processes have been revised (consistent with the project’s intent statement), approved, deployed (i.e. scheduled in System X), placed in the Information Management repository, communicated and trained to the field, and are actively being used for a period of three months before the project is closed.”

Notice that the definition utilizes specific verbs, like “approved,” “communicated,” and “deployed.” Where necessary, it further defines how those verbs should be achieved. For example, the definition notes that the revisions should be consistent with the project’s intent statement, and that “deployed” means that the processes are scheduled in System X. All too often, without this definition, teams finish too early—declaring victory when processes are deployed, and forgetting about the essential tasks of communication, training, and monitoring the finished result.

Here’s another example used by a marketing firm for a deliverable they owed to a client:

• “Our client’s blog is live on their website, pre-seeded with ten relevant posts written by our team that meets all of the defined content guidance.”

This is a simpler definition (since it applies to a specific deliverable). But without this technique, it is common for clients like this to bring different assumptions to the table about when the deliverable is complete. One person might think the task is to simply architect the blog and ensure it is “live.” Another may think two or three “seed posts” are required. A more experienced person with knowledge of SEO may understand that a larger volume of “seed content” is needed. All three may have different assumptions about the level of quality required for those posts. This definition of done clarifies both the number of seed posts needed and the content guidance that must guide the quality of those posts.

Do You Need a Definition of Done?

To discover if your team is clear about their definition of done, look at the milestones on your latest project schedule. Does it utilize non-specific verbs like “Completed,” “Finished,” or “Done?” Next, consider your last few meetings with the team. Do misunderstandings frequently occur over the completeness or quality of deliverables submitted? If the answers to these questions are yes, you may benefit from integrating this question—even informally—into your team discussions.

How to Create Your Definition of Done

Consider the task or project at hand. The most important step in creating a definition of done is not to get it right the first time, but to get something on paper. For example, if you’re working on a project to deploy software, you might start with: “The project is done when the software has passed all required tests and is ‘live’ for all our targeted users.”

Great! Now ask—if I were to dismiss the team and end the project at that point, would that be okay? If yes, your definition of done is probably adequate. If not, ask yourself, what else needs to be done, or what other criteria must be satisfied.

Perhaps, in this example, the configuration documentation also needs to be finalized, approved and archived. If so, add that to your definition. Note or cross-reference any criteria that must be met for the documentation to be approved.

Now, continue this exercise—asking “If all this were achieved, could I dismiss the team and move on to another project?” again and again until your definition of done is complete.

At the project-level, your definition of done may expand to half a page, or a page, or bulleted statements. That’s okay! A formal definition of done should be simple and easy to read, but thorough.

Try It!

Now it’s your turn. Keep this window open for inspiration, and try to write your own for a project or task your team is struggling with. It’s important to consider it a draft until you’ve socialized it with other team members—all key players should have input, as it’s so easy to miss something that those with subject matter expertise would catch!

If you would like feedback on the finished product, we would love for you to send us a generic version (minus any company information)—we will reply with feedback! Send to: ProjectManagement@ThePersimmonGroup.com