The Product Owner has the sole authority on putting the work of the Scrum Team at the end of a Sprint into the hands of users. This means that at the end of a Sprint, after the Sprint Review has occurred, the Product Owner considers the state of the Product (features, quality, performance, etc.) and the state of the business/market, and decides if the product should be sent out.
In an IT or web environment, this means deployment. For other types of software this might be live updates or sending out DVDs to customers. There should be no other individuals who have the authority to do extra releases without the Product Owners approval, nor should there be anyone who can stop a release from going out if the Product Owner makes that decision. If the Product Owner has this authority, it can create a high level of efficiency in addressing the needs of the business or the needs of the market. If the Product Owner does not have this authority, then it undermines their authority over the ordering of the Product Backlog (since that ordering becomes meaningless) and it undermines the broader organization’s ability to hold the Product Owner accountable for results.
Enabling this authority is often difficult except in the smallest organizations. In small organizations such as start-ups, the Product Owner is often the founder and/or a partner and can make the decision easily without bureaucratic obstacles or significant technical obstacles. In larger organizations, there are often many bureaucratic and technical obstacles that need to be overcome before the Product Owner has this level of authority. This relates to the Scrum Team’s “Definition of Done”. Ideally, the Scrum Team produces fully ready software every Sprint, where “ready” includes all the technical tasks, artifacts, processes, qualities and all the bureaucratic tasks, artifacts, processes and standards. Every Sprint! For example, if the system needs user documentation in order to be shipped to customers, then every Sprint, the Scrum Team must make sure the user documentation is up-to-date. The Scrum Team will encounter many obstacles to getting software to this “ready” state and those obstacles need to be vigorously removed by the Scrum Master. Therefore, this state of readiness is an enabler for the authority of the Product Owner. Once that state of readiness exists, then the Product Owner exercises their authority every Sprint by making a conscious decision about shipping or not shipping.
If the Product Owner decides to ship, then it should be as simple as pushing a button with no further “work” required on the part of any Scrum Team member, and should be as fully automated as possible so that there is minimal delay (ideally no delay) in getting the software into the hands of users. Getting to this state of readiness and granting the Product Owner this authority can often take several years of building skills, expanding the Scrum Team’s authority, automating processes, and getting rid of wasteful activities, all of which many have many large and small obstacles to deal with along the way.
If you find this useful, please consider contributing with our
“Value for Value” model.