A 101 coverage of the PO role.

1. September 2016

2. WII-FM
Think about …
 The most important thing I want to know is …
 I want to know how to do …
 How do we deal with …
 What if we could …

3. WHAT IS AGILE?

4. EMPIRICAL PROCESS
CONTROL
Agile is based on empirical control, through
transparency, inspection and adaptation. The best
processes are emerging while doing, and only
retrospectively it is possible to recognize successful
adaptations from non successful ones.

5. PULL PRINCIPLE
Agile approaches are based on pull principle which
allows self-organizing teams to pull in work and
knowledge as needed in order to deliver value to
the customer.

6. AGILE TEAM MODEL

7. THE AGILE MANIFESTO

8. AGILE PRINCIPLES

9. ROLES IN SCRUM

10. SCRUM MASTER
RESPONSIBILITIES
 The PROCESS OWNER
 Helps the team do its best work
 Team level coach
 Facilitates communication
 Acts as a change agent

11. THE DELIVERY TEAM
 Build the thing RIGHT
 Made up of whomever is needed to complete the work
 Decides HOW to build it
 Commit to the Sprint
 Own the estimates and tasks
 Plan their own work (tasks, dependencies)

12. THE SCRUM FRAMEWORK

13. SCRUM PROJECT
LIFECYCLE

14. 5 LEVELS OF PLANNING

15. VISION
Vision Feeds Scope and Priorities
 Visioning exercise should be held with all people who need to
buy in to a common vision of the product and/or strategic
direction
 Elevator Statement
 Design the Product Box
 Press Release

16. LEAN CANVAS

17. PERSONAS

18. ROADMAP
 Emphasizing the setting of high-level objectives, aligned to
goals around value-delivery
 Can be used to define critical dates
 Set high-level themes and direction
 Should indicate planned evolution over time

19. RELEASE PLANNING
 Description
 Team to make a “soft” commitment to the completion of a set of the
highest ranked product backlog items for the upcoming release
 Synchronize the team on the objectives of the Release and the
opportunity to see the bigger picture
 Should be done face-to-face
 Likely that the stories will be further refined and may be split into
smaller (value-focused) stories, AC may be modified, and additional
stories may be created
 This event may last up to 2 days

20. RELEASE PLANNING
AGENDA
 Opening
 Product Vision / Roadmap
Review
 Architecture Review
 Release Name & Theme
 Review Velocity
 Review Release Schedule &
Iterations
 Issues and Concerns
 Definition of Done Review /
Modifications
 Review Stories in
Consideration
 Review Story
 Provide High-level Estimates
 Split Story (if necessary)
 Validate Acceptance Criteria
 Identify Issues & Concerns
 Identify Dependencies &
Assumptions
 Sequences Stories Across
Iterations
 Team Commitment
 Communication / Logistics
Plan
 Close / Mini-retro

21. RELEASE PLANNING
OUTCOMES
 A release plan with team-based
understanding of priorities
 A best-guess sequence for story mappings
to iterations
 High-level story estimates
 Issues, risks, dependencies, concerns to be
monitored throughout the Release

22. WALKING SKELETON

23. PRODUCT BACKLOG
What is it?
• Is the ranked list of all the features and functions to be built
into the system and all the defects to be fixed. At its most
basic it is all the work to be done by the delivery team on
the system.
What’s in it?
• Contains features, requirements, user stories, as well as
defects. These items describe the system to be developed
and they comprise work to be planned and delivered.
• Product Backlog Items (PBIs) that cannot be delivered in
one iteration are called epics.

24. PRODUCT BACKLOG
Who owns it?
• The Product Owner owns the backlog. The PO owns all
decisions about content and ranking.
Who Contributes to it?
• Stakeholders contribute their ideas and needs about what
the system should do.
• The Delivery Team contributes technical stories as well as
estimates.

25. RANK FOR VALUE
Goal of an Agile project is to deliver value incrementally.
Product Backlog must be ranked for value.
Consider value in terms of:
Stakeholder and User Value
• Include the System itself as a stakeholder, whose primary interest is its
own health
Strategy Value
• Does a PBI further the product vision or corporate strategy.
Competition Value
• Can a PBI alter the competitive landscape?
Feedback and Learning
• Early feedback from stakeholders. Technical learning, validating
solutions.

26. PRODUCT BACKLOG
DYNAMICS

27. USER STORIES
User stories are written in everyday language that describe the
interaction between the user and the system, focusing on the
value gained. It is not a highly documented requirement, but
rather a conversation to collaborate on the topic.
A user story should fit onto a 3” x 5” card and will contain 3
parts: the title, the description and the acceptance criteria (AC).
If the title and description don’t fit, then you should revisit the
user story.
As a [user role/who] I want [goal/what], so I can [reason/why]

28. WHO
The who is the “who” who wants the functionality and who
benefits from it. Typically this is a role or persona.
Avoid “As a user…” this is too vague or too general. Use roles to
help the team imagine who they are building the software for.
Helps create a relationship between the team and the “who”.

29. WHAT
This specifies the need, feature or functionality that is desired
by the who. This is what will be built into the software or
service.
Should be clear, so that the team knows what to design and
build.

30. WHY
 Specifies the value for the who and is the primary purpose for
delivery.
 It is important to help teams design solutions that meet the
real needs of the users and customers.
 The “why” is critical as we focus on value driven work . The
“why” keeps the value up front, helping the PO with ranking.
 The team needs to understand the “why”, then come up with
the delivery ideas.
 If there is no “why”, you most likely have a story with no
value!

31. THE 3 C’S
3 C’s indicate the 3 elements of a user story: Card, Conversation
and Confirmation
Card
• Captures the general idea and is a promise for conversation
Conversation
• Through conversation, the PO and delivery team develop shared
understanding of the goals for functionality as well as constraints.
This should be the whole team participating.
Confirmation
• Well defined user story is testable. AC are the conditions of
satisfaction and acceptance for the story.

32. REFINEMENT SESSIONS
Purpose: To provide input regarding clarity, dependencies, risks,
assumptions, acceptance criteria (AC), and high level estimates in
order to inform the prioritization and on-going maintenance of the
Product Backlog.
Attendees: PO, Delivery Team, Subject Matter Experts (SME),
Stakeholders (if needed)
Outcomes:
 Stories have been clarified with any relevant information.
 High-level implementation estimates have been provided by the
Delivery Team that will implement the story.
 The PO is equipped with information to help with prioritization
decisions.

33. REFINEMENT
DESCRIPTION
 A backlog refinement session is intended to provided the PO with
information to keep the Product Backlog healthy.
 This on-going session provides synchronization points with the
delivery team to ensure that the stories are understood and in good
standing to be brought into Sprint Planning.
 This synchronization ensures that estimates are provided, stories are
clarified and that the PO has enough information to prioritize stories
on an on-going basis.
 The whole team should be involved in a backlog refinement session.
 Remember to consider your Backlog Refinement sessions when
calculating your team capacity. A general rule of thumb is to reserve
approximately 10% - 15% of capacity for each team member.
 Any specialists or SME(s) that are needed for a specific story should
also attend.

34. BREAKING DOWN STORIES
The team helps with the work, but the more the PO can own story
breakdown, the more she can ensure meaningful feedback and valuable
stories.
 INVEST in good stories
 Independent, Negotiable, Valuable, Estimable, Sized Appropriately,
Testable
 Vertical Slices rather than Horizontal layers

35. SPLITTING STORIES

36. RANKING THE BACKLOG
 Prioritization Attributes
 User/stakeholder value
 Competition value
 Strategy value
 Revenue value
 Risk
 Kano Analysis
 Story Mapping
 Stack – rank
 #1, #2, #3, #n…

37. SPRINT PLANNING
 What is it?
 PO’s vision for the sprint
 Describes the highest priority features to the team
 Determines the work for the upcoming sprint.
 Items are taken off of the product backlog according to priority and
broken down into manageable tasks.
 Who Attends?
 Product Owner
 Scrum Master
 Delivery Team
 Outputs
 A sprint goal
 A sprint backlog (includes the list of tasks necessary to delivering
the product backlog items

38. SPRINT REVIEW / DEMO
 What is it?
 The Scrum team demonstrates what they accomplished during the
sprint
 Very informal
 Natural result of the sprint
 PO accepts or rejects each product backlog item*
 Stakeholders/business and PO provide feedback
 Who Attends?
 Delivery team
 Scrum Master
 Product Owner
 Customers
 Stakeholders
 Outputs
 Accepted work for the sprint

39. RETROSPECTIVE
 What is it?
 A retrospective is an opportunity to learn and improve. It is time
set aside – outside of day-to-day routine – to reflect on past events
and behaviors.
 Who Attends?
 Product Owner
 Scrum Master
 Dev Team
 Outputs
 Top Items to improve for the next sprint
 Action Items that come out of the meeting

40. DAILY SCRUM
 What is it?
 Daily meeting held by the team
 Not a status or a problem solving meeting
 The team reports to each other on what they accomplish
 Who Attends?
 Product Owner
 Scrum Master
 Dev Team
 Other(s) outside of the Dev team can attend
 Outputs
 None unless there are roadblocks that the Scrum Master needs to
help remove

41. CHIEF PRODUCT OWNER
 This role is the Product Owner (PO) of the whole product.
 The CPO is focused on the strategy of the product and own a shared
product vision for the entire product.
 The individual team PO will also have a shared product vision that will
ultimately align with the overall product vision.
 The CPO owns the single product-level backlog and provides guidance to
the group of PO’s on the Scrum Team(s) that will complete the effort.
 The CPO will use the product-level backlog to coordinate the work through
sub-backlogs, through the individual team PO.
 This role is filled by a single person not a committee.
 This role requires full time focus and commitment to a single product.
 The CPO will facilitate collaborative decision making as well as having the
final say if a decision cannot be reached (handled through sessions such as
the Scrum of Scrums which the CPO will own).

42. SCALING THE PO
Feature and Component Owners - Start-up before Maturity

43. SCALING THE PO
Unbundling and Product Variants – Start-up before Maturity

44. SCALING THE PO
Strategic and Tactical Product Roles - Mature