The Product Owner in Scrum is accountable for the value delivered. Besides the fact that value is a very different driver than volume is, that accountability can hardly be demonstrated without a clearly identified ‘product’. Product is the vehicle to deliver value. Neither can a Product Owner be accountable and effective without a mandate to make decisions.
Organizations often introduce Scrum by constructing teams within existing departments and silo structures. The ‘Product Backlogs’ that they work off may be fascinating collections of work, but they are rarely for a…product. Although ‘product’ determines the scope, span and depth of Scrum, it is one of the most ignored considerations when Scrum is introduced. But…how can you then know what the Product Owner actually owns? What purpose serves Product Backlog if not the single source of work to optimize the value the product delivers? What is it that releasable Increments are being created of when not of a well-defined product? Without a clearly identified ‘product’ optimizing for value is hardly possible and Scrum is hardly used effectively.
When teams work within the confines of a traditional line organization, the highest achievable definition of product is often a part of a system, a component, a module or ‘something’ to be shipped to ‘someone’. Teams deliver work to other teams that in turn combine it with their work or the (system) parts, components or modules they create. And other teams again depend on the work to be received from them. As the diverse teams often operate under different line management, it ends up with nobody minding the synergies across them, with nobody minding the actual…product and the value delivered to end-users. The effective use of Scrum is impeded by mapping it to the old delivery structures and keep producing the same parts and modules for the same sub-products.
The challenge is to know your product or service so you can start organizing your Scrum to best serve the people consuming it!
Following knowing the product, the mandate and autonomy for a Product Owner is the next tactical challenge to tackle. Is your Product Owner the best placed person to make business decisions or is your Product Owner a proxy, a distant representative, a temp like a project manager or some other intermediary? Are the decisions by your Product Owner fully supported or does your Product Owner have to check in with managers, directors or the steering committee before making a decision? Any decision?
Regardless, the minimal purpose of the Product Owner role in the Scrum framework is to inject and uphold the business perspective in the product development work. The Product Owner connects the worlds of (1) product management and the business side of the organization (think: market research, sales, finance, legal, marketing), (2) the user and customer base and (3) the delivery or development parts of the organization.
Connecting those worlds includes engaging with them to be assure that all product management aspects and the wider business perspective are integrated into the actual development. In the other direction it allows the Product Owner to keep stakeholders and product management people up to date on the actual development progress, so they can organize or re-organize their work accordingly. Being a connector is not the same as being a bottleneck. Product Owner, not information barrier.
Still, the Product Owner is the one person making the final call on the order of the work in the Product Backlog. Product Backlog shows all the work currently envisioned for the product, all work that potentially increases the value that the product delivers. Smart Product Owners show openness for great ideas whatever their source or origin and they gracefully employ skills of development people to convert product ideas and business solutions into requirements. Product Owner, not product dictator.
The Product Owner manages Product Backlog based on the product vision as a longer-term view of the road ahead. A product vision captures why the product is being built and why the product is worthwhile investing in. A product vision helps the Product Owner set or reset specific goals, hopes and dreams, express the expectations and ideas captured in the Product Backlog better and better order the items in the Product Backlog for value.
If anybody wants to know what work is identified and planned for the product, it suffices to look at the Product Backlog, at one artifact only. If they want to understand what is planned for or what is in the product, and why, it suffices to ask the Product Owner, one person only.
Sprint Review is a great opportunity for a Product Owner to learn about the assumed or actual value that the product delivers. At the Sprint Review (key) stakeholders, the team and (potentially) consumers or (key) users collaborate over what got done and what didn’t get done, what influenced the work and what was the purpose of that work. But value as the overall purpose is a very different driver than volume is (the amount of tasks executed and features implemented). The purpose of Sprint Review is not reporting or justification but to share relevant information on usage, competition or market trends that will help optimizing for value in the next Sprint(s). The goal is to collaboratively identify what is the most valuable work to do next for the Product. This is evidently captured in the living artifact that Product Backlog is.
Being a Product Owner certainly implies expectations, skills and traits that go beyond those for a traditional requirements engineer, a requirements provider or similar. Product Owner, ideally, is the owner of the product. Such ownership of a product implies strong organizational adoption of the role. It allows a Product Owner to act like a product-CEO (again, not a product dictator). That accountability of the Product Owner cannot be mapped on existing roles or functions, deliverables and meetings. The role simply did not exist in the industrial paradigm.
Note. This article is based on texts that are taken from my current book-in progress “Views from the House of Scrum” (to be released in 2021).
Gunther Verheyen is a longtime Scrum practitioner. After a standing career as a consultant, he became partner to Ken Schwaber (Scrum co-creator) and Director of the Professional series at Scrum.org. Gunther nowadays engages with people and organizations as an independent Scrum Caretaker.
Gunther ventured into IT and software development after graduating in 1992. His Agile journey started with eXtreme Programming and Scrum in 2003. Years of dedication and employing Scrum in diverse circumstances followed. As from 2010 Gunther became the inspiring force behind some large-scale enterprise transformations. In 2011 he became a Professional Scrum Trainer.
Gunther left consulting in 2013 to found Ullizee-Inc and partner exclusively with Ken Schwaber, co-creator of Scrum. He represented Ken and Scrum.org in Europe, shepherded the ‘Professional Scrum’ series and guided Scrum.org’s global network of Professional Scrum Trainers. Gunther is co-creator to Agility Path, EBMgtTM (Evidence-Based Managing of Software) and the Nexus framework for Scaled Professional Scrum.
Since 2016 Gunther continues his journey as an independent Scrum Caretaker; a connector, writer, speaker, humanizer. His services build on 15+ years of experience, ideas, beliefs and observations of Scrum. Gunther helps people re-imagine their Scrum to re-emerge their organization and firm up their agility.
Gunther created the acclaimed book “Scrum – A Pocket Guide” in 2013 and published a 2nd edition in 2019. Ken Schwaber recommends it as ‘the best description of Scrum available’ and ‘extraordinarily competent’. In 2016 the Dutch translation was published as “Scrum Wegwijzer” and in 2017 the German translation as “Scrum Taschenbuch”. More translations are forecasted.
When not travelling for Scrum and humanizing the workplace, Gunther lives and works in Antwerp (Belgium). More at https://guntherverheyen.com/about/.
Gunther is the author of the acclaimed book “Scrum – A Pocket Guide” (2013), which was recommended by Ken Schwaber as “the best description of Scrum currently available". A second edition was published in 2019 and a third edition is planned for 2021.