The Scrum Product Owner Theses

This content is syndicated from Age of Product by Stefan Wolpers. To view the original post in full, click here.

TL;DR: The Scrum Product Owner in 56 Theses

The following 56 scrum product owner theses describe the role of the PO from a holistic product creation perspective.

The 56 product owner theses cover the concept of the product owner role, product discovery, how to deal with external and internal stakeholders, product roadmap planning, as well as the product backlog refinement. The theses also address the product owner’s part in scrum ceremonies such as sprint planning, sprint review, and the sprint retrospective.

Product Owner Theses: Scrum from Product Discovery to Product Delivery

Product Owner Theses: The Role of a Product Owner

This first set of theses addresses the product owner’s role in the scrum process:

  • A product owner embraces, shares, and communicates the product vision. They represent both the customer and internal stakeholders.

  • on the process, a product owner is the gatekeeper of the product backlog, and thus “owns” the product on behalf of the organization as well as customers.

  • A product owner is responsible for maximizing the value that the product provides to both customers and the organization.

  • To maximize the value of a product, the product owner must be empowered to make all product-related decisions on behalf of the organization.

  • If a product “owner” is not empowered to “own” the product, they are not a product owner per se, and the organization is not practicing scrum.

  • A product owner is the sole representative of the stakeholders, internal and external, insofar as the development team is concerned.

  • A product owner owns the “why”, and influences the “who” and “what”, but should never be concerned with the “how”. Progress in product development is always a collaborative, team effort.

  • A product owner must work closely with the core scrum team, and particularly the scrum master or agile coach — their natural ally.

  • A product owner should actively participate in scrum ceremonies, especially the product backlog refinement, sprint planning, and sprint acceptance ceremonies.

  • A product owner needs to be co-located with the scrum team to avoid delays, communication errors, and other problems caused by distance.

  • Contrary to popular belief, a product owner is neither a user story author nor a requirements engineer, but rather a communicator and facilitator between the stakeholders and the scrum team.

Product Owner Theses: Product Discovery and External Stakeholders

These theses concern what’s required of the product owner on product discovery and product management:

  • A product owner must have a holistic understanding of problems and opportunities: in the market, inherent to the product itself, with the organization and its strategy, and of concern to the various stakeholders.

  • The job of a product owner is to create value for both customers and the organization while mitigating risk.

  • A product owner creates value by embracing a continuous product discovery process built around learning and experimentation.

  • During the product discovery process, a product owner validates hypotheses by continuously running experiments.

  • Frameworks and methodologies suitable for the product discovery process include A/B testing, Business Model Canvas, Continuous User Testing, Design Sprints, Design Thinking, Lean Startup, Lean UX, and Rapid Prototyping — to name just a few.

  • A product owner must be capable of thinking regarding systems to deal with complexity.

  • The earlier a product owner is involved in a product’s lifecycle, the more valuable that product owner will be to the organization.

Product Owner Theses: Internal Stakeholder Management

The following theses concern specific aspects of the relationships between product owners and their internal stakeholders:

  • A product owner needs to gain the trust and mandate of all internal stakeholders.

  • A product owner must be able to explain to any internal stakeholder at any time how the stakeholder’s requirements are accommodated by the product vision.

  • Regular feedback from internal stakeholders is crucial to a product owner’s work being successful — specifically, their success with creating the hypotheses funnel that they use to run experiments.

  • Close cooperation between a product owner and their organization’s customer care and sales teams is particularly beneficial for product success.

  • A product owner must be empowered by the organization to say “No” to a stakeholder’s requests — no matter how powerful the stakeholder is.

  • A product owner’s communication with internal stakeholders needs to be transparent and regular to encourage these stakeholders to be engaged with the scrum team.

  • The scrum master is a good ally for a product owner in the pursuit of internal stakeholder engagement.

  • Good opportunities for a product owner to engage internal stakeholders are scrum ceremonies, like the sprint acceptance (demo); workshops, such as user story mappings; or training sessions, whereby stakeholders are taught how to better communicate with the scrum team.

  • Internal stakeholders make excellent members of customer development or user research teams, and a product owner should seek to secure their participation in these activities.

Product Owner Theses: Product Roadmap Planning

The theses in this set concern one of the most contentious topics in the profession: “How do we build agile product roadmaps that work?”

  • A product owner’s role requires that they also act as a product manager, which means that they must define the product vision, perform strategy and market research, develop business models, manage the product lifecycle, and facilitate product portfolio and roadmap planning. (For more detail, refer to Roman Pichler’s The Scrum Product Owner Role on One Page.)

  • An agile product roadmap is a high-level plan that describes how the product vision is likely to be accomplished. It should facilitate experimentation and learning.

  • An agile product roadmap is based on objectives and is usually theme- or goal-oriented.

  • An agile product roadmap is not a prioritized list of features with fixed shipping dates for months to come. (For more detail, refer to my 7 Best Practices on How to Build a Product Roadmap.)

  • Usually, product roadmap planning in larger organizations with several products requires that each product owner aligns his or her efforts with other product owners to synchronize product development.

  • A product roadmap addresses strategic aspects of product planning. A product backlog addresses technical development issues.

  • Roadmap planning is, like product backlog refinement, a continuous effort — just at an increased cadence.

  • Product owners communicate “big product pictures” by using techniques like user story mapping. (For more detail, refer to Jeff Patton’s User Story Mapping.)

  • A product owner needs to be familiar with the five levels of agile planning: defining the product vision, defining the product roadmap, release planning, sprint planning, and accounting for the outcome of daily scrums.

  • Relying on a committee of stakeholders for product discovery and portfolio management is the most common reason that agile product delivery initiatives fail.

Product Owner Theses: The Product Backlog and User Story Creation

The theses in this section concern a product owner’s home turf: the product backlog, and user story creation.

Product Backlog

  • A product owner is much more than the “project manager of the product backlog”, and must do more than churning out user stories on behalf of stakeholders. (A.k.a. “ticket monkey syndrome”).

  • Product backlog refinement is a continuous process that needs to be in sync with the product discovery process.

  • Typically, a scrum team will collaboratively refine product backlog items for the upcoming two or three sprints.


Hands-on Agile: The Scrum Product Owner in 56 Theses
Click To Tweet


User Story Creation

  • Creating user stories does not equal breaking down requirements documents received from stakeholders into smaller chunks.

  • Writing user stories is a collaborative effort involving the entire scrum team. The process should create a shared understanding of what will be built, and for what reasons.

  • Because it’s a collaborative effort, a user story is a subject of discussion for the scrum team. This might take up to 10% of the team’s availability during a sprint.

  • A product owner will need to come to an agreement with their team as to what standards user stories need to achieve before being considered suitable for the sprint backlog (i.e. defining and achieving the “Definition of Ready”).

  • Planning poker — the process of estimating user stories — is, most importantly, knowledge transfer. It supports the creation of a shared understanding within the scrum team of what needs to be built.

  • User story estimation is a critical part of the risk mitigation strategy for the scrum team.

  • With respect to the “Definition of Ready”: a candidate for the role of product owner should have heard of Bill Wake’s INVEST acronym (from the article INVEST in Good Stories and SMART Tasks).

Product Owner Theses: Sprint Planning, Reviews, and Retrospectives

The final set of theses concern product delivery: the sprint itself.

  • A product owner defines the scope of upcoming sprints by identifying and prioritizing the most valuable user stories in the product backlog.

  • A product owner should participate in all scrum ceremonies related to sprints.

  • The product owner is the person responsible for defining a sprint’s goal.

  • A product owner understands that, in addition to user stories, technical tasks, bugs, and research need to be addressed in every sprint. (For more detail, refer to Barry Overeem’s The Backlog Prioritisation Quadrant.)

  • A product owner should be available on short notice to clarify any questions that the scrum team may have during a sprint.

  • A product owner is responsible for accepting user stories into each sprint, and for deferring user stories that require additional work to meet the ‘Definition of Ready’ standard. This does not apply to user stories that are related to technical or refactoring tasks. The decision on those is the prerogative of the scrum team.

  • A product owner is responsible for deciding whether to release a product increment at the end of each sprint.

  • A product owner should host the sprint review, which is an event meant to provide the scrum team an opportunity to demo the outcome of each sprint to the product’s stakeholders.

  • A product owner must embrace the sprint review as a vital inspect and adapt feedback loop — for both the development team and the product’s external and internal stakeholders.

Conclusion: The Product Owner Theses—Scrum From Product Discovery to Delivery

I believe that the scrum product owner role is the most demanding of all three scrum roles. It covers a lot of ground, from product discovery, politics, and stakeholder management to systems thinking, and maximizing the return on investment for his or her team.

It is also the scrum role that the dark side can misuse simpler than the two other roles.

Am I missing product owner theses to describe the scrum product owner correctly? Please share with me in the comments.

Related Posts

Scrum: 19 Sprint Planning Anti-Patterns.

28 Product Backlog and Refinement Anti-Patterns

Hiring: 42 Scrum Product Owner Interview Questions to Avoid Agile Imposters

The post The Scrum Product Owner Theses appeared first on Age of Product.

Leave a Reply

Your email address will not be published. Required fields are marked *

13 + ten =


There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”

GINA MILLARD
GLASS'S INFORMATION SERVICES

“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”

LUKE SHARKEY /STRATEGY & IMPLEMENTATION LEADER
SUNCORP

“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”

GILES BENTLEY, DEVELOPMENT & OPERATIONS DIRECTOR
TIME INC

“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”

PETER THATCHER, SENIOR ACCOUNT DIRECTOR
ThoughtWorks

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”

BRUCE WEIR/EGM
SUNCORP

“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”

JULIE PEEL
GLASS'S INFORMATION SERVICES

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”

PETER SILVA-JANKOWSKI
IPC MEDIA

“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”

HANNAH JOYCE
GLASS'S INFORMATION SERVICES

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”

BEATRIZ MONTOYA/CONSUMER MARKETING DIRECTOR
IPC MEDIA

“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”

ANDY JEFFRIES/TECHNICAL LEAD
IPC MEDIA

CONTACT US

To explore how we can help you, please get in touch