Product Owners want a perfect Definition of Done. Here’s why.

Product Owners want a perfect Definition of Done

First, it’s worth revisiting and reacquainting yourself with the Scrum Guide’s Increment section before we explore why Product Owners seek a perfect Definition of Done.

Below is an example list of activities that represents potentially releasable. If all activities were completed the product could be released to a customer.

Definition of Done - Example

Definition of Done

The Definition of Done is an agreed list of criteria that the product will meet for each Product Backlog Item. The Definition of Done applies to all Product Backlog items. If more than one Scrum Teamwork on the product they share the same Definition of Done

The initial Definition of Done must be created and agreed upon before the first sprint. Its forms an input into Sprint Planning to guide the Scrum Team on what tasks they’ll need to perform to turn Product Backlog Items into a potentially releasable increment each sprint.

To do this define what activities are needed to release to end customers. We’ll call this list “Potentially Releasable”. With this list then define which activities can be done each sprint. This forms the “Definition of Done”. The difference between the two lists is undone work. The undone work must be completed at some point before release. This is not partially completed work.

Weak Definition of Done

If the Definition of Done only contains the underlined items from the Potentially Releasable list then the following behaviours will be observed:

Iteratively and incrementally a product is built according to the weak Definition of Done. This leaves undone work to build up each sprint.

  • The impact of this on the Product Owner and organisation is that they cannot release the product until the undone work is done
  • The undone work builds exponentially making it harder and harder to forecast likely completion dates. Transparency and visibility is reduced as we don’t really know where we are in development.
  • If we defer releasing to customers to later sprints it increases the risk of building the wrong features.
  • If we cannot release it reduces the Product Owner’s ability to adapt to risks and opportunities as they are not able to change strategic direction. Release of value and validation is delayed. Value is diminished
  • If testing and validation are deferred to later sprints it increases the risk of poor design and technical debt leading to rework. Imagine if we defer Performance or Acceptance Testing for 4 sprints. We are not learning whether the product is sufficient to meet the service level agreements. The amount of rework could be extensive.
Weak Definition of Done

This leads to results very similar to a waterfall approach.

Comparing Evolutions

Work towards a perfect Definition of Done == Potentially Releasable

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. The closer we are to done each sprint the better decision we can make for the next.

This graphic represents a perfect Definition of Done.

  • At least once per sprint, we have met the Definition of Done.
  • If the Product Owner wants to release it to the customer they can.
  • No undone work remains at the end of the sprint. All activities are done in the sprint
  • Transparency is high as we always know where we are up and are able to forecast our trajectory toward our product goal. We can make decisions about what’s next and change strategic direction when needed without being dragged down by undone work.
Perfect Definition of Done enables empiricism

Scrum will shine a light on organisational impediments in the way of agility. Defining Potentially Releasable will help identify people, technology, domain, and internal and external dependencies that hold back agility. The Definition of Done is inspected and adapted sprint by sprint becoming closer to Potentially Releasable. This will involve breaking down organisational boundaries and removing dependencies which further increases the maturity of Scrum Teams increasing their cross-functionality, decreasing the complexity of the organisation and its products over time.

Looking to learn how to get started with a Definition of Done? Take a look at our blog, “Creating a Definition of Done.

Thanks for reading and if you want to learn way more about product ownership, scrum mastery, and product development check out our courses.

Stay in the loop on all things agile

Make sure you do not miss out on any news! Join our mailing list for a monthly newsletter bursting at the seams with need-to-know information about b-agile and the industry!

  • This field is for validation purposes and should be left unchanged.

By completing this form you are agreeing to our privacy policy