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

Before we explore why Product Owners want a perfect Definition of Done, it is worth re-reading the Increment section of the Scrum Guide.

Below is an example list of the activities that make an Increment potentially releasable. If every activity were completed, the product could be released to a customer.

The Definition of Done

The Definition of Done is an agreed list of criteria the product will meet for every Product Backlog item. It applies to all of them, and if more than one Scrum Team works on the product, they share the same Definition of Done.

The initial Definition of Done must be created and agreed before the first Sprint. It is an input to Sprint Planning, guiding the Scrum Team on the work needed to turn Product Backlog items into a potentially releasable Increment each Sprint.

To create it, first define the activities needed to release to end customers. Call that list "potentially releasable". Then define which of those activities can be done every Sprint. That is the Definition of Done. The difference between the two lists is undone work. It must be completed at some point before release, and it is not the same as partially completed work.

A weak Definition of Done

If the Definition of Done contains only the underlined items from the potentially releasable list, here is what happens.

The product is built iteratively and incrementally to the weak Definition of Done, and undone work builds up every Sprint.

• The Product Owner and the organisation cannot release until the undone work is done.
• Undone work grows exponentially, making it harder and harder to forecast completion dates. Transparency falls, because nobody really knows where development is.
• Deferring release to later Sprints increases the risk of building the wrong features.
• If you cannot release, the Product Owner cannot adapt to risks and opportunities or change strategic direction. Value and validation are delayed. Value is diminished.
• Deferring testing and validation increases the risk of poor design and technical debt, and so of rework. Imagine deferring performance or acceptance testing for four Sprints. You are not learning whether the product meets its service level agreements, and the rework could be extensive.

The results look very much like waterfall.

Work towards a perfect Definition of Done, where Done means potentially releasable

Scrum relies on transparency. Decisions to optimise value and control risk are made on the perceived state of the artefacts. The closer you are to Done each Sprint, the better the decisions you can make for the next.

This graphic represents a perfect Definition of Done:

• At least once per Sprint, the Definition of Done is met.
• If the Product Owner wants to release to customers, they can.
• No undone work remains at the end of the Sprint. Every activity is done within it.
• Transparency is high. You always know where you are, you can forecast your trajectory towards the Product Goal, and you can decide what is next and change direction when needed without being dragged down by undone work.

Scrum shines a light on the organisational impediments in the way of agility. Defining potentially releasable surfaces the people, technology, domain and internal and external dependencies that hold agility back. The Definition of Done is then inspected and adapted Sprint by Sprint, getting closer to potentially releasable. That means breaking down organisational boundaries and removing dependencies, which in turn matures the Scrum Teams, increases their cross-functionality, and reduces the complexity of the organisation and its products over time.

Ready to create one? Read Definition of Done: where to start for a practical three-step approach.

To go deeper into product ownership, our Professional Scrum Product Owner course is the place to start.