Product Owners want a perfect Definition of Done. Here’s why.
First it’s worth reading this section of the Scrum Guide http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done to reacquaint yourself with the formal definition.
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
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 Team work on the product they share the same Definition of Done
The initial Definition of Done must be created and agreed before the first sprint. Its forms an input into Sprint Planning to guide the Development Teams 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 different 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 Owners 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 is 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.
This leads to results very similar to waterfall
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 represent a perfect Definition of Done.
- At least once per sprint we have met the Definition of Done.
- If the Product Owner wants to release to the customer they can.
- No undone work remains at the end of 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 towards product goals. We can make decisions about what’s next and change strategic direction when needed without being dragged down by undone work.
Scrum will shine a light on organisational impediments in the way of agility. Defining Potentially Releasable will help identify people, technology, domain, 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 complexity of the organisation and its products over time.
Thanks for reading and if you want learn way more about product ownership, scrum mastery and product development check out our courses.