Demystifying the Role of Product Owner

AT12
Concurrent Session
11/14/2013 3:45 PM

"Demystifying the Role of
Product Owner"

Presented by:
Bob Galen
RGalen Counsulting Group, LLC

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Bob Galen
RGalen Consulting

Bob Galen is an agile coach at RGalen Consulting and director of agile
solutions at Zenergy Technologies, a North Carolina-based firm
specializing in agile testing and leading agile adoption initiatives. Bob
regularly speaks at international conferences and professional groups on
topics related to software development, project management, software
testing, and team leadership. He is a Certified Scrum Master Practicing,
Certified Scrum Product Owner, and an active member of the Agile Alliance
and Scrum Alliance. Bob published Scrum Product Ownership: Balancing
Value from the Inside Out, which addresses the gap in guidance toward
effective agile product management. Contact Bob
at bob@rgalen.com or bob.galen@zenergytechnologies.com.

Demystifying the
Product Owner Role

Bob Galen
President & Principal Consultant
RGCG, LLC
bob@rgalen.com

Introduction
Bob Galen
n 
n 
n 
n 
n 
n 
n 
n 

Somewhere ‘north’ of 30 years experience J
Various lifecycles – Waterfall variants, RUP, Agile, Chaos…
Various domains – SaaS, Medical, Financial Services, Computer
& Storage Systems, eCommerce, and Telecommunications
Developer first, then Project Management / Leadership, then
Testing
Leveraged ‘pieces’ of Scrum in late 90’s; before ‘agile’ was ‘Agile’
Agility @ Lucent in 2000 – 2001 using Extreme Programming
Formally using Scrum since 2000
Currently an independent Agile Coach (CSC – Certified Scrum
Coach, one of 50 world-wide; 20+ in North America)
q 

n 
n 

at RGCG, LLC and Director of Agile Solutions at Zenergy Technologies

From Cary, North Carolina
Connect w/ me via LinkedIn and Twitter if you wish…
Bias Disclaimer:
Agile is THE BEST Methodology for Software Development…
However, NOT a Silver Bullet!

Copyright © 2013 RGCG, LLC

4

1

Outline

n 
n 
n 
n 
n 
n 

Introduction
Role of the “Product Owner”
Product Backlogs
Sprint Dynamics
Goals & Criteria
Role of the Product Owner at-Scale
Q&A


5

The SCRUM Framework


6

2

Roles in the SCRUM Framework
Lets get the team
together and figure
this out!
Our burn-down is off,
what’s going on?

How do I drive value?

Team Member
n 

Product Owner
• 
• 
• 
• 

Contributes to Product
Backlog and Goals
Prioritizes the backlog
Typically a product
manager
Accepts the teams’ work

n 
n 
n 
n 

n 

Cross-functional role: QA +
Dev + Doc + Arch. + etc.
7 +/- 2 in size
Teams are self-organizing
Focused teams
Members should be fulltime
co-located whenever
possible

Scrum Master
• 
• 

• 

Scrum PM like role
Responsible for enacting
Scrum values and
practices
Main job is to remove
impediments


7

Inside Out?
n 

Many Product Owners are conflicted…
q 
q 
q 
q 

Training
Overloaded
Time allowed
Domain & Customer familiarity

n 

Serious role within Scrum and should be handled that
way

n 

Premise: Product Owners first responsibility is towards
their Team!
ü 
ü 
ü 
ü 

Backlog & work orchestration
Interaction & feedback
Goal setting & acceptance
Leadership & partnership


8

3

4 Quadrants of
Product Ownership
1.  Product Manager
q 

q 

2.  Project Manager
q 
q 
q 

q 

3.  Leader

Product Roadmap,
Collateral, Business Case /
ROI
Driving customer value

Product Backlog (WBS)
Grooming & look-ahead
Velocity-based, Release
Planning
Goal setting, Budget

q 
q 
q 

Trade-offs, product balance
Stakeholder “management”
Member of the team;
partner with the Scrum
Master

4.  Business Analyst
q 
q 
q 

Story writing
Acceptance
Emergence; Spikes


9

Scrum Guide
Product Owner Definition
The Product Owner is responsible for maximizing the value of the
product and the work of the Development Team. How this is done may
vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes:
q 
q 

q 
q 

q 

Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and
missions;
Ensuring the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all,
and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands


10

4

Scrum Guide
Product Owner Definition
The Product Owner may do the above work, or have the Development
Team do it. However, the Product Owner remains accountable.
For the Product Owner to succeed, the entire organization must respect
his or her decisions. The Product Owner’s decisions are visible in the
content and ordering of the Product Backlog. No one is allowed to tell
the Development Team to work from a different set of requirements,
and the Development Team isn’t allowed to act on what anyone else
says.

Scrum Guide, October 2011 version, except from page 5
http://www.scrum.org/Scrum-Guides

11

Scrum Guide
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways,
including:
q 
q 

q 

q 
q 
q 

Finding techniques for effective Product Backlog management;
Clearly communicating vision, goals, and Product Backlog items to the
Development Team;
Teaching the Scrum Team to create clear and concise Product Backlog
items;
Understanding long-term product planning in an empirical environment;
Understanding and practicing agility; and,
Facilitating Scrum events as requested or needed.

Scrum Guide, October 2011 version, except from page 7
http://www.scrum.org/Scrum-Guides

12

5

Agile Atlas (Scrum Alliance)
Definition
The Product Owner is the single individual who is responsible for drawing out
the most valuable possible product by the desired date. This is done by
managing the flow of work into the team, selecting and refining items from the
Product Backlog. The Product Owner maintains the Product Backlog and
ensures that everyone knows what is on it and what the priorities are. The
Product Owner may be supported by other individuals but must be a single
person.
Certainly the Product Owner is not solely responsible for everything. The whole
Scrum Team is responsible for being as productive as possible, for improving
their practices, for asking the right questions, for helping the Product Owner,
and so on. The Development Team is responsible for determining how much
work will be taken on in a Sprint, and for producing a usable Product Increment
in every Sprint.


13

Agile Atlas (Scrum Alliance)
Definition
n 

Nonetheless, the Product Owner, in Scrum, is in a unique position. The
Product Owner is typically the individual closest to the "business side" of the
project. The Product Owner is typically charged by the organization to "get
this product out", and is typically the person who is expected to do the best
possible job of satisfying all the stakeholders. The Product Owner does this
by managing the Product Backlog, and by ensuring that the Product
Backlog, and progress against it, is kept visible.

n 

The Product Owner, by choosing what the Development Team should do
next and what to defer, makes the scope versus schedule decisions to lead
to the best possible product.

www.agileatlas.org - September 2013

14

6

Community Disagreement
over the Role

n 

Single individual or collaborative group?
q 

n 

Scrum Yahoo Group there was discussion in the Fall of 2008 regarding
whether it could be done by a small group. Schwaber stated that “there
can be only 1”.

Oh, and are they a part of the team?
q 
q 
q 

Scrum team vs. Development team
For example, do they attend the Sprint Retrospectives?
Can they perform work within the Sprint?


The Product Owner
Is…
n 

n 

Provides the Product Vision –
where the team “going”; shares
the voice of the customer
(VOC)

n 

Needed to be available daily
for work feedback, acceptance,
and scope adjustment
discussions

n 

Communicates externally to
Stakeholders and buffers the
team from potential
distractions

n 

Accountable for the teams
results meeting business
expectations

The primary “keeper” of the
teams’ Product Backlog
q 

q 

n 

15

Required to provide a balanced
and nuanced Product Backlog
A writer of requirements that
are well defined, granular, and
most importantly testable

Is responsible for considering
the capability of their team
(skills, strengths, weaknesses,
#’s, etc.) and setting the
Backlog to amplify successful
execution


16

7

The Product Owner
Is not…
n 

The manager of the team; nor responsible for performance management.
They can give performance feedback, but only when requested to do so.
This is the Functional Managers responsibility

n 

A decider of technical direction (architecture, design, etc.), that is the Teams
responsibility

n 

A contributor to Story or Task estimates; that is the Teams responsibility

n 

Responsible for the overall skill of the team; selecting team members; or
fighting for individuals. The Functional Managers tries to effectively balance
the teams


17

Product Owner role according to
Roman Pichler
n 
n 
n 
n 
n 
n 
n 
n 
n 
n 

Product Vision
Product Business Model (value & benefit)
Product Roadmap Planning
Collaborate with the Scrum Master and Development team
Describe UX and Features
Determine Goals (Sprint)
Research / Validation for Feedback (effective Reviews, etc.)
Review Feedback & Adjust – Feature(s) and Roadmap
Look after the Budget
Coordinate Launch

http://www.romanpichler.com/blog/roles/the-product-owner-responsibilities/

Copyright © 2013 RGCG. LLC

18

8

Ownership/Role Balance

n 

Product Owner owns: What

n 

Team Owns: How and How

n 

Long
Scrum Master owns: Agile Principles &
Practices
Challenge & discuss – Yes; but in the end, TRUST the
ROLES!


19

Product Backlogs


20

9

Product Backlog
Simple list, or something else?
n 

All work vs. feature work? One list vs. many?
q 
q 

n 

Features, Technical, Quality, Release, etc.
Excel Product Backlog Items (PBIs) vs. User Stories vs.
something else altogether? Connecting to other artifacts?

How do you orchestrate or influence – Emergent
Practices?
q 
q 
q 

Not writing Too Much…Too Soon
Architecture, feature sets, usability, design, etc.
Balancing look-ahead?


21

Where do User Stories
“Come From”?
n 

Stories come from:
q 
q 
q 

n 

Customer wants/needs; bugs, maintenance, technical debt
Product Owner capturing individual stories; team members
User Story Writing Workshops

Who writes them?
q 
q 
q 

Initially – the Product Owner or individual team members
Eventually – everyone “touches” them via Backlog Grooming
It Takes a Village!


22

10

Product Backlog as…
WBS?
n 

Partitioning the Backlog - workflow
q 
q 
q 

n 
n 
n 
n 
n 

Opening Moves – emergent understanding, beginning well
Middle Game
– stabilization, value, mass
End Game
– integration, quality, customer delivery

Design or look-ahead activity
Features
Dependencies & X-team hand-offs
Iterations & Milestones
Transparency & “progress tracking”


23

Iceberg Model


24

11

Backlog ‘Tension’ Points
n 

n 

n 

How many items? Size – does it matter? Are they all the
same?
Prioritization & Valuation methods?
FutureCast – painting a compelling picture of the
“Tactical Now” vs. the “Strategic Later” w/o scaring
everyone to death…
Granularity heuristic

Use the 20/30/50 rule. 20% proper stories ready to roll. 30% are epics bigger stories that will eventually be split out into smaller fine
grained ones (only as needed). The last 50% are themes - vague
ideas about long term product direction and I never put much effort
here because it’s almost always wrong.

25

Grooming your Backlogs
Approaches?
n 

The Product Backlog is Organic and needs
care & feeding
q 

q 

n 

Reserve time for collaborative, team-based
grooming meetings OR ‘Assign’ individual stories to
team members
Combination of these two

Keeping it interesting, grooming at 3 levels:
q 
q 

q 

20%: what’s right around the corner – are we ready?
30%: what’s 3-4 sprints away – are we getting
clearer?
50%: what’s the future looking like? Break those
things down…


26

12

Grooming your Backlogs
Look-ahead
n 

Judicious use of Research Spikes to gain understanding;
output of a Spike:
q 

Knowledge, solid stories, prototype code, design(s), tooling, etc.

n 

In some cases, run Iteration #0 types of exploratory
iterations to get broad information under your feet

n 

Always looking for new ‘contributions’
q 
q 

Technical, quality, release workflow, etc.
Rarely do they seem to be forthcoming; encourage them from the
team


27

Active Backlog Grooming
n 
n 
n 
n 
n 

n 

n 

Bring goals & stories to the table; but be open to change
Listen actively
Don’t predetermine size nor complexity; trust your team
Don’t negotiate…collaborate
Organic explorations of scope and options as you get
closer to execution
Explore execution dynamics – architecture & design,
testing, non-functional, deployment, and risk
Apply pressure on – value flow, quality & sustainable
pace


28

13

A Tapestry that Includes Threads for…
Things to do…
n 
n 

n 
n 
n 
n 
n 

Features
Value
increments
Architecture
Design
Process
Quality
Testing

In a Context-Based
fashion…

n 
n 
n 
n 
n 
n 

n 

Deployment
Regulatory
Dependency
Risk
Feedback
Customer
timing
Tempo

…Guiding us
towards
customer
value


29

User Stories
Hierarchical Types
n 

Epic – a huge idea, spanning multiple teams and multiple sprints.
Could be several releases. Rarely well understood.

n 

Theme – a large idea; spanning multiple teams, but normally fitting
into a release. Normally a simple marketing container – for planning
& prioritization.

n 

Feature – a large idea; spanning multiple teams, always fitting into
a release. Assigned team owner.

n 

User Stories – work items for a given sprint. Well understood. All
work delivered in story-units.


30

14

User Stories
Hierarchical Types
Hierarchy
Epic

Theme or
Feature
Story

Attributes

Visited

• 
• 
• 

Defer planning precision - Visioning • 
Container, X-teams
Roadmap & Portfolio Level Planning

Annually, phased
planning,
roadmap
forecasts

• 
• 

Container, potentially X-teams
Release Level Planning (1-2
releases ahead)
High Level Research – Feature
Spike

• 

Quarterly to
monthly
Track feature
delivery

Team work item
Can be quite large (13 – 20 points)
Sprint Planning
Low Level Spikes

• 

• 
• 
• 
• 
• 

• 

• 

Monthly to
Sprintly
Track story
delivery


31

Product Backlog Wall

Source: http://mhjongerius.tumblr.com/post/16222404998/our-new-product-backlog-wall


32

15

Sprinting


33

Sprint Dynamics
Planning
n 

Always be ready; strategize with your
Scrum Master
q 
q 
q 

No surprises for the team!
You’re part of the team, stay engaged in the entire process
Drive everything with ‘goals’

Point of Sprint Planning
1. 
2. 

To share and gain the teams’ commitment toward the Sprint Goal
To identify the set of User Stories that align with and are feasible
to deliver within the Sprint
3.  To identify the Tasks associated with delivering those User
Stories
In that priority order and leading to goal-driven work


34

16

Remember -- The Triad
Customer
Collaboration
FIRST…
Automation
SECOND…

Ken Pugh has
written a book on
ATDD and uses
the “Triad” to
amplify this
collaborative
pairing between
roles…Product
Owner is central
to that!

Collaboration
Developer

Tester
35

Sprint Dynamics
Execution
n 

Stay engaged
q 
q 
q 

n 

Looking-ahead
q 
q 

n 

Attend daily Scrum
Observe the trending; consider adjustments as the sprint evolves
Actively participate…perhaps in testing; certainly in grooming

Grooming the Backlog in ALL dimensions
Collaborating with Customers & Stakeholders

Observe & understand your team dynamics
q 

Strengths, capabilities, weaknesses, etc.


36

17

Sprint Dynamics
Execution
The very next day, the Product Owner gave me a call. Again, 5 a.m. on
the west coast, but hey… he had a Sprint progress observation and
wanted my advice. He said it seemed clear that the team was going
to miss delivering some of the features for the Sprint.
However, he was OK with that and wanted to know if he could start
removing or reframing Stories in order to increase the teams ability
to meet the Sprint Goal?
So, here’s a Product Owner who, in their very first Sprint, gets the
difference between planned scope versus actual team capacity and
the need for ongoing adjustments. Ah Ha—I thought!


37

Sprint Review
A Defining Moment
n 

Take ownership of attendance
q 

q 
q 

n 

Ensure key stakeholders are going to
attend; If not, ask them to send someone
Make it compelling to them; sell the opportunity
Same ‘ceremony’ every Sprint?

Help the team prepare
q 
q 
q 

Have a ‘script’; don’t over-prepare, but DO NOT wing it
Product Owners should “Set the Stage” for the Sprint
It’s not simply about features
n 

q 

Other artifacts, test automation, prototypes, etc.

Whole team approach


38

18

Sprint Review
A Defining Moment
n 

Serve as the M/C of the review
q 
q 

n 

Call it! At a Story level and at a Sprint level…
q 

n 

Ensure clarity of communication
Pace & transitions

Pass or Fail?

Connect the dots
q 
q 
q 

Relative to challenges in the sprint
Relative to release goals
Relative to customer expectations


39

Review Flow
§  Organized & Thoughtful Flow
q 
q 
q 
q 
q 
q 
q 
q 
q 

Introduction
Team Chart
Acknowledgements - Appreciations
Sprint Goal
Strategy? Success? Efforts? Discoveries? Results?
Demo’s; Q&A
Coming Attractions
Fist-of-Five Towards Improvement
Close


40

19

Sprint Retrospective

n 

And as a member of the team…
Attend the retrospective
q 
q 
q 
q 
q 

Actively participate
Bring in an outside “business perspective”
It’s ok to share your pressures
Quality impressions; Continuous Improvement impressions
Focus on Predictability, Quality, and Value


41

Goals


42

20

Leading with Goal Setting
ü  Release Goals
ü  Sprint Goals
ü  Feature Acceptance

n 

n 
n 
n 

Over Features,
Stories, and Tasks
Value-driven
Envisioning
Chartering


43

Establishing Goals & Criteria
Why it’s Crucial?
n 

Agile teams are essentially
self-directed, so plans don’t drive behavior or success…

n 

People do and Goals drive the Team!

n 

The team then swarm around the goal(s), using their
creativity and teamwork to figure out:
q 
q 
q 

What’s most important
How to achieve it
Always looking for simple & creative—20% solutions


44

21

Notions of Done-ness
n 

n 

Need to define “Done” from team
members perspectives
If you’re a developer, what does
“I’m done with that story” mean?
ü 
ü 
ü 
ü 
ü 
ü 
ü 

n 

Code complete
Code reviewed (paired)
Checked in – build successful
Unit tests developed – passed
Integration
QA collaboration
Run by the Product Owner

Every type of task should have a definition of done-ness!
How else could you estimate the work?


45

Story Acceptance
n 

Each User Story should have acceptance criteria as part
of the card

n 

They should focus on the verifiable behavior, business
logic, for the story

n 

Typically, they are crafted by the Product Owner
q 

n 

Leveraging skills of Business Analysts and Testers

Story acceptance tests are normally automated and run
as part of feature acceptance AND regression


46

22

User Story
Examples
As a dog owner, I want to sign-up
for a kennel reservation over
Christmas so that I get a
confirmed spot

Verify individual as a registered pet owner
Verify that preferred members get 15% discount on basic service
Verify that preferred members get 25% discount on extended services
and reservation priority over other members
Verify that past Christmas customers get reservation priority
Verify that declines get email with discount coupon for future services


47

Iteration / Goal Acceptance
n 

Each Scrum Sprint has a Product Owner determined
Sprint Goal

n 

Usually sprint success is not determined by the exact
number of completed stories or tasks

n 

Instead, what most important is meeting the spirit of the
goal
Deliver a 6 minute demonstration of the software that
demonstrates our most compelling value features and achieves
venture capital investment interest


48

23

Release Criteria
n 
n 

Goals and objectives for the entire project release
Usually they are multi-faceted, defining a broad set of
conditions
q 
q 
q 
q 
q 
q 

n 

Required artifacts
Testing activities or coverage levels
Quality or allowed defect levels
Results or performance metrics achievement levels
Collaboration with other groups
Compliance levels

That IF MET would mean the release could occur.


49

Levels of Criteria
Activity

Criteria

Basic Team
Work Products

Done’ness criteria

User Story or
Theme Level

Acceptance Tests

Sprint or
Iteration Level

Done’ness criteria

Release Level

Release criteria

Example
Pairing or pair inspections of code prior to check-in; or
development, execution and passing of unit tests.
Development of FitNesse based acceptance tests with the
customer AND their successful execution and passing.
Developed toward individual stories and/or themes for sets
of stories.
Defining a Sprint Goal that clarifies the feature
development and all external dependencies associcated with
a sprint.
Defining a broad set of conditions (artifacts, testing
activities or coverage levels, results/metrics, collaboration
with other groups, meeting compliance levels, etc.) that IF
MET would mean the release could occur.
Contributed to Chapter 20 of Lisa Crispin &
Janet Gregory’s new 2009 Agile Testing book


50

24

Who Decides on Quality?
n 

Of Course, Quality isn’t a simple pattern, it’s a façade

n 

Jim Coplien responding to a point on Scrum Alliance
leadership list (paraphrased)…

Value doesn’t matter when examining technical debt. Rather, that cleaning up
after yourself transcended the normal determination of business value and
was simply an inherent part of delivering software. That it is our
responsibility and is non-negotiable. The decision-making wasn’t FOR the
business-side, but instead resides within the team.

n 
n 

Listen to your team!
Ask the ‘Right’ questions!


51

Role of the Product Owner
At Scale


53

25

Chartering
Chartering Components
q 
q 

q 
q 

q 

q 
q 
q 

Project visioning
Shared stakeholder
expectations
Goals & Success criteria
Approaches, Process,
Methods
Team, Communication,
Metrics
Scope & Budget
Risk handling
Sign-off

Agile Practices
q 
q 

q 

q 
q 
q 

Road-mapping
Backlog grooming, Story
writing
Collaborative release
planning
Crystal – Blitz Planning
Patton – Story-Mapping
XP – Planning Game


54

Product Management
n 

Facilitating high level visioning
q 
q 

n 
n 
n 

Competitive landscape
Technology and corporate direction

Chartering of new projects
Product Road-maps & release orchestration
Story development
q 
q 
q 

Epic -> Feature (MMF) -> Story stream
Priority & value
Technical clarity (quality, architecture, technical debt)


55

26

Portfolio Management
n 

Something similar to the Lean Dog – Big Visible Room
for executives to
q 

n 

http://www.slideshare.net/LeanDog/agile-from-the-top-down

Instead of an electronic dashboard,
q 
q 
q 
q 

Vision, Portfolio, Assignments, Value, ROI
Release plans, application funnel
Capability and competency
Agile practices / team alignment


56

Scrum of Scrums
n 

n 

Periodic meeting – similar to
daily stand-up
Focus:
q 

q 

q 
q 

n 

X-team interactions,
dependencies, and blocks
Release planning &
communication
Frequency dictated by state
Information radiators: release
burndown, impediments, etc.

Key reference
q 

http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-ofscrums-meeting


57

27

Scrum of Scrums board
Story + Status (across teams)

Source: http://www.xqa.com.ar/visualmanagement/2009/08/scrum-of-scrums-making-it-visual/


58

In Closing…
n 

Product Ownership (by the Customer, Stakeholder, BA,
Product Manager) is the most crucial role within agile
teams, providing—
ü 
ü 
ü 
ü 
ü 
ü 

Inspirational vision
Clear goal – setting; quality balanced
Prioritized requirements – value based, workflow
Measured & accepted results
Scaled appropriately
Focus towards the team first


67

28

Wrap-up

• 

What were the most compelling
ideas, stories, or lessons?
What adjustments will you make in your Product
Ownership?
What ideas did I miss?

• 

Final questions or discussion?

• 

• 

Thank you!

68

Contact Info
Bob Galen
Principal Consultant,
RGalen Consulting Group, L.L.C.

Experience-driven agile focused training,
coaching & consulting
Contact: (919) 272-0719
bob@rgalen.com
www.rgalen.com

Blogs
Project Times - http://www.projecttimes.com/robert-galen/
BA Times - http://www.batimes.com/robert-galen/
Podcast on all things ‘agile’ - http://www.meta-cast.com/


69

29

Demystifying the Role of Product Owner

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (16)

Semelhante a Demystifying the Role of Product Owner

Semelhante a Demystifying the Role of Product Owner (20)

Mais de TechWell

Mais de TechWell (20)

Último

Último (20)

Demystifying the Role of Product Owner