Three key tips for making sure ‘done’ means done - Unlock Your Team's Genius

Three key tips for making sure ‘done’ means done

By Georg Fasching | agile practice

Sep 05

Learn the purpose and value of defining the term ‘done’ in agile product management

Tip 1: Insure against accidents

Establishing the definition of ‘done’ for a sprint item is a very important step of agile product management. See it as an insurance policy for the product owner (and thus the end-user) and a measure of fidelity and quality assurance. It is the balancing act to the team’s Definition of Ready.

It ensures the team executing the work are consistent in their delivery. The product owner can use it as a benchmark to assess whether the team have delivered exactly as agreed when they pulled the work into the Sprint. If they have then the feature can be formally accepted by the PO and released to the end user, leaving the team with a warm, fuzzy feeling of the value they delivered.

Tip 2: Create clarity

It’s equally important to be very specific in your definition of done. Be as clear as possible and be sure every member of the team understands the criteria for ‘done’ in the same way. Some examples of criteria are as follows:

  • It solves for the user need
  • It meets the acceptance criteria
  • It has been tested and passed all agreed automated and manual testing criteria

Once everyone’s on the same page, communicate your own definition of done to the relevant stakeholders and product owners for maximum transparency. The clarity of your alignment with the stakeholder landscape, and product owners of related product areas, should improve as a result of this too.

Tip 3: Proportional Definition of Done over the product lifecycle

Just like the definition of a ‘ready’ item for Sprint Planning, the definition of a ‘done’ item is ever evolving. These are definitions that are jointly owned by the Scrum Team. Scrum’s event’s offer good opportunities for a potential need to update the definitions.

You can expect your ‘done’ definition to be very different at the beginning of your product’s life cycle compared to the end. That said, don’t be afraid to grow it and mature it, which begs the question how often should you update it. Your inspect and adapt frequency for this agreement might be once every 2-4 weeks at the start of the product life cycle, and once a quarter once things are more stable, your mileage may vary depending on context.

“Your definition of done will be different when you’re validating and prototyping to later on when you’ve achieved product market fit”

The reason for this is simple. At the start, the team are far more concerned with validating key assumptions of the product through prototyping. Speed is of the essence. For testing many assumptions some very low fidelity prototypes by the team may be sufficient. By the end of the early days, the team will have (hopefully) achieved product/market fit. It is now time to gradually upgrade fidelity and quality levels as appropriate.


I hope these tips help you to understand and establish your own definition of ‘done’ for your backlog. As a result, the increased clarity between team members will improve understanding, reduce risk and enable them to deliver real value consistently.

If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!


About the Author

An agilist since 2010 and in product management since the 90s, Georg Fasching helps digital creative agencies delight their clients, fulfil their people, and improve their prosperity.