We started this Scrum foundation series explaining we see four underlying concepts of the Scrum framework. In the past series of mails we covered the three pillars of Empiricism, the Scrum Values, and a Self-Managing and Cross-Functional Team.

The concept Done is the fourth of these concepts. It needs a self-managing, and especially a cross-functional team, a team living the Scrum Values, to make it work in a way that it brings the needed transparency with regards to the quality of your solution/product.

👉 A solution (Product/Increment/Service) the team labels as Done, meaning the solution meets the required quality measures, is ready to be released in the hands of the users, in their day-to-day life.

Being Done = meeting the required quality measures = a new Increment exists = a production release is possible.

Done should receive the necessary attention by each of the Scrum Accountabilities.

When the Increment is not Done, then nothing can be provided to the users, and therefore there is no additional value they receive. 

Given the Product Owner is accountable to maximise the value of the product, getting to Done is very important; it’s key!

But given that it are the Developers who are creating that usable – Done – Increment, what can a Product Owner do to support them?

Some ideas:

Understand the Definition of Done as a Product Owner. Provide input to it: what quality is expected by the market, what do you know competitors are covering from a quality perspective.
Ensure, with the team, that the Sprint Goal and selected PBI are realistic to get to Done at least once a Sprint.
Ensure Product Backlog Items (PBI) are understood before being taken up in Sprint Planning.
Have Developers connected with the right users and other stakeholders before work is undertaken so there are no delays when additional input is needed during the Sprint.
Be available for the Developers when they still have questions during the Sprint.
Actively listen to Developers when quality issues are being discussed. Is it a one-off issue that once solved is really gone, or is there a fundamental issue with the product – what Developers call Technical Debt? Make sure this is dealt with.

These are just a few examples.

When it comes to Done, the Product Owner can best support the Developers by ensuring beforehand they have a strong understanding about Product Backlog Items, about expected quality levels, and about the right connections with users and stakeholders in case additional clarifications are needed during the work.

Together with your Scrum Team, evaluate how the Product Owner can support the use of your Definition of Done, and to keep improving it.

We hope you will find value in these short posts and if you are looking for more clarifications, feel free to take contact.

PS. Next week we’ll look at the use of Done and the Developers.


If you want to take a deeper dive into the core concepts we are covering in this blog series, then surely check out our Professional Scrum MasterY workshop. We have some scheduled in the coming period.


Don’t want to miss any of these blog posts? Have the professional Scrum foundations series weekly in your mailbox.

Leave a Reply