Definition of done6 min read

Something I’ve seen in many companies is that, when it comes to workflows, the “done” state is either unclear or not properly documented and, hence, was being incorrectly applied. I think that this can be a serious issue becase, as Seneca wrote in one of his letters to Lucilius: when a man does not know what harbour he is making for, no wind is the right wind.

In order to achieve the best outcome from our work, we need to know when our work is actually complete. If we don’t, we face the risk of delivering low-quality products after very inefficient efforts.

Therefore, I think it’s essential that every team and company documents their definition of done. In this post, I’m going to elaborate what my definition is and how I applied it in the redesign of this blog.

My definition of “done”

Based on my 5+ years of experience as a Product Manager in 4 different tech companies, I’ve come to conclude that there is no one-size-fits-all definition of done. This definition will highly depend on:

  • The nature of the task that’s being defined
  • The nature of the product or service that the task is impacting
  • The nature of the team and the company in which the task is being worked on

That being considered, we can say that a task is done when all of the acceptance conditions or criteria are met.

In order for the acceptance criteria to be met, there are three key actions that need to take place:

  1. The acceptance criteria is clearly defined
  2. The acceptance criteria is documented and accessible
  3. The reporter or main stakeholder reviews the task and checks whether the acceptance criteria are met

These three key actions have one thing in common: they need to be performed by the main stakeholder or reporter of the task. Let’s analyse them in more detail.

Defining the acceptance criteria

The acceptance criteria is a collection of actions that are expected to happen once the task is finished, and highly depends on the nature of the task.

Defining the acceptance criteria is key if we want an effective outcome of the task, and the reporter of the task is responsible for doing this.

If we consider introducing a new feature on a website as a general example, the acceptance criteria could be:

  • Passing the original unit tests
  • Adding new unit tests
  • The code is reviewed by another developer
  • Passing the functional tests
  • Documenting the functionality

As a more concrete example, let’s consider changing the fonts of this website. The acceptance criteria will be:

  • The new body font is Maven Pro, its weight is 500 and its size is 17px
  • The new title font is Playfair Display, its weight is 900 and the font size is does not change
  • The new fonts are correctly loaded on phone, tablet and desktop browsers
  • The new fonts are present in all elements of the website: the header, the body, the footer, the image captions, the blog tags.

Documenting the acceptance criteria

In order for the team of person to know what they have to work on, the acceptance criteria must be documented in either the task ticket itself if you use software like todoist or Jira, or anywhere where the person who is going to work on it can access it easily.

This means that the task reporter must write down the acceptance criteria in a clear, understandable manner.

Using the redesign of the blog as an example, I documented the necessary changes in a todoist task where I had two main subtasks, as follows:

  1. Implementation
    1. Change body font to Maven Pro, with weight = 500 and size = 17px
    2. Change title fonts to Playfair Display, with weight = 900 and same sizes as before
  2. Testing
    1. The new fonts are correctly loaded on phone, tablet and desktop browsers
    2. The new fonts are present in all elements of the website: the header, the body, the footer, the image captions, the blog tags.

As I implemented the changes I ticked off the respective acceptance criteria from the Implementation subtask in todoist. This way, I ensure that the acceptance criteria is being met.

Reviewing that the acceptance criteria are met

Although this step is as critical as defining the acceptance criteria, it’s usually overlooked. There are several reasons for this:

  • The acceptance criteria is not properly documented and accessible or not documented at all.
  • Reviewing that the acceptance criteria is met is wrongly perceived as a waste of time or signs of micromanagement.

I agree that defining, documenting and reviewing acceptance critieria can be time consuming and not particularly fun at times, but again, they are critical if we want the best possible output and outcome from a task.

Reviewing that the acceptance criteria are met is fairly straightforward: the reporter needs to go criteria by criteria and ensure that they are met.

If any of the acceptance criteria isn’t met, the task is considered as not done and is returned to the person who is working on it.

Coming back to the example where I change the fonts of the website, let’s assume that I go through the acceptance criteria and discover that the fonts are not loading on phones. The review will look something like this:

  • ✅The new body font is Maven Pro, its weight is 500 and its size is 17px.
  • ✅The new title font is Playfair Display, its weight is 900 and same sizes as before.
  • ❌The new fonts are correctly loaded on phone, tablet and desktop browsers.
  • ✅The new fonts are present in all elements of the website: the header, the body, the footer, the image captions, the blog tags.

Since there is one acceptance criteria that is not being met, the task is considered as not done until the font is also displayed on phone browsers.

The importance of workflows in the definition of done

In order to ensure the success of correctly applying the definition of done, there needs to be a process that empowers its usage and application.

I know, the word “process” doesn’t sound very enticing. However, without it it’s very likely that the acceptance criteria aren’t being defined, documented and reviewed.

In order to support these three actions, a process should have at least the following steps:

  • Task definition: the reporter describes what the intended outcome of the task is, as well as defining and documenting the acceptance criteria.
  • Task review: after the task has been worked on, it is assigned to the reporter so that they are the ones who set it as done.

Having these steps as non-negotiable steps in the workflow will ensure that the quality and efficiency of the output of the tasks being worked, since it will make it easy for the definition, documentation and review of the acceptance criteria.

Conclusion

Although there is no one-size-fits-all definition of done, there are three key actions that ensure that a task is correctly categorised as done:

  1. Definition of the acceptance criteria.
  2. Documentation of the acceptance criteria.
  3. Review of the acceptance criteria once the task has been finished before considering it as done.

Ensuring that the team or organisation you work with understands the definition of when something is done is essential in Product Management.

Therefore, it’s your responsibility to champion its application by setting the example and performing the three key actions described above, as well as demonstrating their importance with results.

Leave a comment