Why should a Product Manager care about: the Definition of Done?
“That thing is just technical stuff right? I wouldn’t know where to find it.” Frequently I run into Product Owners that find it hard to find the importance in what I believe is one of the most important elements of the Scrum Framework.
We often find very technical Definitions of Done and as a result Product Managers in a Product Owner role stop caring or refer to it as geek-speak. That is however not the purpose of the Definition of Done.
At the heart of Scrum is the constant beat of “Done” increments. A metropolitan commuter doesn’t care when the subway departs since a fresh one will arrive minutes later which can be boarded as well. The heartbeat of done increments allow the Product Manager to release “at will.” The Product is always in a shipable state.
It’s important we all agree what that state is, so as s Product Manager it can mean that each increment is:
- fully integrated, performs within specifications, is stable but also
- has release notes, internationalisation for relevant countries and
- been verified with users, system and user documentation is up to date
- shared with marketing sales, supply chain, finance and channel management
The Definition of Done does not need to be technical but can we very useful to make sure that the whole organisation knows what it is that we are releaseing.
“Hold on, if we are going to do all that, we won’t get around to coding?” Yes, this will impact the amount of code a team can produce. But just like commuter doesn’t care about a set of wheels, chairs or even entire subway wagons it is the whole that is used, and it is the whole that must be done.
As a Product Manager, ask yourself: can I truly release every iteration? if the answer is no: fix it. No one trusts a subway that runs at random intervals and delivers coaches that are “almost done.”
This blog is part of a mini-series called: “Why should a Product Manager care about?”.
