Friday, January 20, 2012

Product Owner Role explained...

I've been cleaning my computer up and I had a look on past training programs. So I felt on a questionnaire that send to my customer a couple a years ago to customize the Product Owner Training.
After re-reading, I think that was no that stupid and I will use this approach again till now.

So, please readers, you can find below this questionnaire inspired by my Product Ownership gurus: Jeff Sutherland, Ken Schwaber, Alistair Cockburn, Scott Ambler, Jochen Krebs, Johanna Rothman, Roman Pichler, Anna Forss and my "Product Owner's Helpdesk" Community fellows on LinkedIn.

... and you can understand why I'm so often pissed of during Agile presentations....

theme details Estimation Status
Introduction Agile Values, Scrum Benefits and Origins
Scrum and Change
How would your life change with Scrum?
Companies Using Scrum
Scrum Process and Roles Scrum Flow
Scrum Roles: Product Owner, Team, ScrumMaster
Product Owner Product Owner Characteristics
A Day in the Life of the Product Owner
The Product Owner as the Voice of the Customer and Value Stream Manager
Requirements Understanding the Customer
Vision The Product Vision
Benefits of the Product Vision
The Vision in Action
Desirable Qualities
Techniques for Creating a Powerful Vision
Creating Product Goals
Backlog The Product Backlog
Determining the Release Scope
Stocking the Product Backlog
Prioritizing the Product Backlog
Refining the Product Backlog
User Stories on the Product Backlog
Case study and simulation
Stocking the product backlog Failure of upfront thinking
Emergent requirements
User stories on the product backlog
Augmenting the user stories
User roles
INVEST in your backlog
Visioning and The Product Vision The Kano Model
The Product Backlog
Requirements in Scrum
Product Backlog Characteristics
Product Backlog Structure and Form
Stocking the Backlog
Grooming the Backlog
Prioritising the Backlog
Getting the Backlog Ready for Sprint Planning
Progressive Requirements Decomposition
Refining Requirements
Collaborative Requirements Workshops
User Stories on the Product Backlog
Non-functional Requirements
Day one retrospective
Prioritizing the product backlog The right size for prioritizing
Prioritization Techniques: Kano analysis, Analytic Hierarchy Process
Theme screening
Theme scoring
Relative weighting
Priority poker
Responsibilities Project responsibilities
Developing the core
Release Management Sustainable Pace
The Project Levers
Defining and Communicating Project Success
Release Management Strategies
The release planning meeting
Estimating Product Backlog Items Using Story Points and Planning Poker
Choosing the Sprint Length and Determining Velocity
Fixed date planning
Fixed scope planning
Creating the Release Plan
Tracking and Reporting the Project Progress
Sprint Management Sprint Workflow and Characteristics
Formulating Powerful Sprint Goals
Sprint Planning, Daily Scrum, Sprint Review and Retrospective
Understanding the Sprint Progress
Getting to Done 
Portfolio Management The Planning Onion
Why Portfolio Management Matters
Levelling the Demand
Portfolio Management Steps
The Portfolio Bubble Chart
Large and Distributed Scrum Projects Brook’s Law
Organic Growth and Conway’s Law
Master Product Backlog and the Product Owner Team
Team Set-up
Multi-team Planning and Coordination
Shared Norms and Assets
Distributed Scrum Project Tips

So, think now if this guy is just a proxy or customer's representative?


  1. just linked this article on my facebook account. it’s a very interesting article for all.

    Scrum Process

  2. The product owner is someone who has an in-depth knowledge about business needs for the product being delivered. The product owner has to be an individual as the decision making power cannot be given to a team. If there is a team of stakeholders that helps the product owner, the final decision making power should lie with the product owner .

  3. This comment has been removed by a blog administrator.

  4. Thanks Dale,

    As a trainer, I prefer that people come to follow my trainings or at least understand the gap between basic scrum training and real business cases.
    One good thing with education is to understand the limits of your sales activities.