When reading the Scrum Guide and discussing the Definition of “Done” the conversation always includes something about the Increment. After all, the Definition of “Done” facilitates transparency of the Increment. However, one thing that is often breezed over or not mentioned at all is how the accountability of roles comes into play when discussing the Definition of “Done” for a Scrum Team.
This post is one in a multi-part series on the Definition of “Done”.
The Definition of “Done” helps baseline communications between individuals so we know what work was performed to turn a Product Backlog Item into a “Done” Increment that is usable condition. Who would be communicating about the Increment with the assistance of the Definition of “Done?” The Development Team and the Product Owner minimially.
The Product Owner’s accountability is to maximize the value of the product. Likely, they want to realize that value through release and adoption of that product and not carry around a bunch of held inventory. The Development Team’s accountability is to deliver a potentially releasable Increment of “Done” product at the end of each Sprint. How they do this is up to them, and the Definition of “Done” helps describe what they do to get a PBI to that potentially releasable state. I would also think that Development Teams also want to release their work and get some personal satisfaction of people using this thing they just created.
This is a good tension. Product Owners always want something they can consider for release. Development Teams use their professionalism to determine what it takes to turn an idea into something we could release. Jointly we inspect that work and make decisions about whether to release or not.
From the Scrum Guide:
The increment must be in useable condition regardless of whether the Product Owner decides to release it.
and
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
To me, the accountability here is on the Development Team to ensure that anything they say is “Done” is also releasable, because the choice to release it is not in their hands once they say it’s “Done.” That accountability lies with the Product Owner. Together they must work out what that level is for their product given their knowledge, skill, and professionalism. And that definition should change and grow as these people do.
If a Definition of “Done” is so intense by either the Development Team’s choice (mistakenly or professionally determined) or by imposed organizational standards such that they cannot create a “Done” Increment of potentially releasable product every Sprint, then my take is the primary thing they should be working on is changing their process and tooling in such a way that they can meet that Definition of “Done” each Sprint. The current processes and tooling are counter to the goal of having an Increment of “Done” product so they need to adapt. Until they can make these changes and produce an Increment of “Done” product by the end of a Sprint, there will likely be Sprint Reviews without an Increment and hopefully a lot of open conversation about what the Development Team is doing to change that with the support the of rest of their Scrum Team and the organization to achieve that.
One last thought: we should be careful not to project our biases as to what “releasable” means in terms of work effort. We can nudge the people we work with to adopt new practices, automation, and things we believe are great ways of achieving high quality products, but if we’re not on that Development Team it’s really not our call to define what it takes to be releasable. They do that through their Definition of “Done.”