I recently delivered a talk to product owners at Cisco. While I would normally cover this stuff over a period of two days, this was a 90 minute talk about some of the aspects of product ownership. None of this is my own creation - for I have learnt all this from the practitioner community, I am more than happy to share it with the community.
Note: If any attribution is missing, I will be happy to correct my mistake :)
5. How Apple does it?
Steve Jobs gave a small private presentation about the
iTunes Music Store to some independent record label
people. My favorite line of the day was when people
kept raising their hand saying, "ʺDoes it do [x]?"ʺ, "ʺDo
you plan to add [y]?"ʺ. Finally Jobs said, "ʺWait wait —
put your hands down. Listen: I know you have a
thousand ideas for all the cool features iTunes could
have. So do we. But we don'ʹt want a thousand
features. That would be ugly. Innovation is not about
saying yes to everything. It'ʹs about saying NO to all
but the most crucial features.”
hNp://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html
11. 12 Agile Principles
Our highest priority is to
satisfy the customer
through early and continuous
delivery
of valuable software.
Welcome changing
requirements, even late in
development. Agile processes
harness change for
the customer'ʹs competitive
advantage.
Deliver working software
frequently, from a
couple of weeks to a couple
of months, with a
preference to the shorter
timescale.
Business people and
developers must work
together daily throughout the
project.
Build projects around
motivated individuals.
Give them the environment
and support they need,
and trust them to get the job
done.
The most efficient and
effective method of
conveying information to and
within a development
team is face-‐‑to-‐‑face
conversation.
Working software is the
primary measure of progress.
Agile processes promote
sustainable development.
The sponsors, developers,
and users should be able
to maintain a constant pace
indefinitely.
Continuous aNention to
technical excellence
and good design enhances
agility.
Simplicity-‐‑-‐‑the art of
maximizing the amount
of work not done-‐‑-‐‑is
essential.
The best architectures,
requirements, and designs
emerge from self-‐‑organizing
teams.
At regular intervals, the team
reflects on how
to become more effective,
then tunes and adjusts
its behavior accordingly.
16. Product Runways
Strategic Vision
Set by the CEO / Board and
consists of Strategic
Direction, Solution Strategy,
Technology Initiatives and
Themes
Reviewed annually as part of
annual strategic planning
and revised as needed
Serves as a strategic input for
product vision
Product Vision
High-‐‑level overview of
product requirements owned
by respective POs
Acts as true north for the
product in long term (3-‐‑5
years)
Serves as the input for
overall product roadmap in
medium term (1-‐‑3 years)
Product Roadmap
Calls out the high-‐‑level
themes and release timeline
in next 1-‐‑3 years
Consists of swimlanes
(strategic priorities vs. lights
on, client requests,vs.
competitive intel, technical
debt vs innovation ideas,,
etc.)
Reviewed each quarter by
Product Council
Product Backlog
Prioritized list of features
identified for the next 1-‐‑3
releases
Owned and maintained by
respective POs based on
relative prioritization of each
feature request
Revised constantly based on
evolving inputs and refined
weekly in grooming sessions
with scrum team
Sprint Backlog
Consists of highest-‐‑priority /
highest-‐‑value features agreed
upon for development in the
current sprint (1-‐‑4 weeks)
Product Owner responsible
to prioritize the features,
while scrum team
responsible for planning,
estimation, planning,
execution and completion of
those features in a sprint
Once the sprint has started,
any new requirements or
change request must wait
until the next sprint planning
17. Adaptive Planning
Product Backlog
Product Roadmap
Sprint Backlog
Product Vision
Futuristic
picture of the
product
Based on
technology
evolution,
market
development,
industry
trends, etc.
Reviewed
annually,
and revised
as needed
High-‐‑level
wish list of
themes and
epics for a
long-‐‑term
Reviewed
by Product
Council on a
quarterly
basis
Typically
revised
annually
Prioritized
list of
Themes,
Epics and
User Stories
Gets
constantly
revised and
groomed on a
weekly basis
Well-‐‑
groomed
User Stories
Can’t be
changed once
the sprint is
underway
Current Sprint
3-‐‑6 months
12-‐‑24 months
1-‐‑3 years
Small Stories,
Firm Requirements,
Large Stories / Epics / Themes,
Fuzzy / Evolving Requirements
Predictable delivery of Features
FlexibilitytoaccommodateChanges
19. Product Vision
Shared by All
Desirable and Inspirational
Clear and Tangible
Broad and Engaging
Short and Sweet
20. Product Vision – Elevator Pitch
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
hNp://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html
24. MoSCoW
• Describes a requirement that must be satisfied in the final
solution for the solution to be considered a success.
MUST
• Represents a high-‐‑priority item that should be included in
the solution if it is possible. This is often a critical
requirement but one which can be satisfied in other ways if
strictly necessary.
SHOULD
• Describes a requirement which is considered desirable but
not necessary. This will be included if time and resources
permit.
COULD
• Represents a requirement that stakeholders have agreed
will not be implemented in a given release, but may be
considered for the future.
WON'ʹT
25. Minimal Marketable Feature
A Minimal Marketable Feature (MMF) is a feature that is minimal,
because if it was any smaller, it would not be marketable. A MMF is
marketable, because when it is released as part of a product, people
would use (or buy) the feature.
An MMF is different than a typical User Story in Scrum or Extreme
Programming. Where multiple User Stories might be coalesced to
form a single marketable feature, MMFs are a liNle bit bigger. Often,
there is a release after each MMF is complete.
An MMF doesn’t decompose down into smaller sub-‐‑feature, but it is
big enough to launch on its own.
A MMF can be represented as a User Story — a short, one-‐‑sentence
description.
29. Benefits of Product Roadmap
Helps communicate how you see the product develop.
Helps align the product and the company strategy.
Helps manage the stakeholders and coordinate the
development, marketing, and sales activities.
Facilitates effective portfolio management, as it helps
synchronise the development efforts of different products.
Supports and complements the product backlog. This
allows the backlog to focus on the tactical product
development aspects.
hNp://www.romanpichler.com/blog/agile-‐‑product-‐‑management-‐‑tools/agile-‐‑product-‐‑roadmap/
31. Product Backlog
A combined list of all desired work, including user
focused stories, technical work, features & ideas
Everything is expressed in User Stories
List is prioritized by the Product Owner
Product Owner keeps it organized with the team’s help
Anyone can add items to the backlog
Evolves over time
Always in progress
32. Product Backlog
v The agile product backlog is a
prioritized features list, containing short
descriptions of all functionality desired
in the product.
v When using Scrum, it is not necessary to
start a project with a lengthy, upfront
effort to document all requirements.
v Typically, a Scrum team and its product
owner begin by writing down
everything they can think of for agile
backlog prioritization. This agile
product backlog is almost always more
than enough for a first sprint.
The Scrum product backlog is then
allowed to grow and change as more is
learned about the product and its
customers.
v hNp://www.mountaingoatsoftware.com/
scrum/product-‐‑backlog
37. Many Projects, One Team
hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow
38. One Project, Many Teams
hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow
39. Many Projects, Many Teams
hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow
40. From Product Roadmap to Product Backlog
hNp://www.romanpichler.com/blog/agile-‐‑product-‐‑management-‐‑tools/agile-‐‑product-‐‑roadmap/
41. Who owns Product Backlog?
hNp://www.romanpichler.com/blog/agile-‐‑product-‐‑management-‐‑tools/agile-‐‑product-‐‑roadmap/
42. Sprint Backlog
v User Stories
selected by the
Team
v Will be built in
current Sprint
v Fully Estimated
v Divided into
Tasks
43. Potentially Shippable Increment
v Most agile processes require development teams to built an increment of product
functionality every iteration, or Sprint. Scrum and Extreme Programming require that
this increment be potentially shippable, if the customer desires to implement the
functionality. This usually requires that the increment consist of thoroughly tested
code that has been built into an executable, and the user operation of the
functionality is documented, either in Help files or user documentation. If the
product increment that is created during the iteration has more exacting use, the
development organization usually defines the additional product requirements as
standards or conventions.
v For example, the Federal Drug Administration (FDA) must approve a product that will
be used in life critical circumstances by in numerous health care seNings if the product
is to be used in the United States. As part of the approval process, the FDA checks that
specific information regarding the product is provided, such as requirements
traceability and specific functionality operation. For each increment to be potentially
shippable, these additional facets of the product must also be developed ñ so that each
increment of the product is potentially ready for FDA approval.
v Similarly, some products require that performance requirements be modeled and the
performance demonstrated mathematically, not just through statistical measurement of
the actual system. The model with all required rigor is thus an additional part of each
iteration ís potentially shippable increment.
hNp://cf.agilealliance.org/articles/system/article/file/970/file.pdf
44. Backlog Grooming
v Upto 10%
of sprint
time
v Creating or
refining
new PBIs
v Estimating
PBIs
v Prioritizing
PBIs
50. The Three C’s of a User Story
• The story itself
• A promise to have a conversation at the
appropriate time
Card
• The requirements themselves
communicated from the PO to the Delivery
Team via a conversation
• Write down what is agreed upon
Conversation
• The Acceptance Criteria for the story
• How the Delivery Team will know they
have completed the story
Confirmation
51. What makes a good User Story?
Independent of all others
Negotiable not a specific contract for features
Valuable or vertical
Estimable to a good approximation
Small so as to fit within an iteration
Testable in principle, even if there isn’t a test for it yet
hNp://guide.agilealliance.org/guide/invest.html
54. “Done”
• Defines the good working development
practices that will be delivered with each
item as it is ready for acceptance
• Common entries in Definition of Done:
• Code includes unit tests, reviewed, checked in
• Tests described and executed
• Build, release notes
• Compliance documentation updated to include current functionality
• Satisfies agreed-‐‑upon acceptance criteria
• Done focuses on internal quality
• Applies to all items in Product Backlog “Building the thing right”
• Acceptance criteria focuses on external
quality
• Functionality “Building the right thing”
55. Epics
v A Scrum epic is a large user story. There'ʹs no magic threshold at
which we call a particular story an epic. It just means “big user
story.” I like to think of this in relation to movies. If I tell you a
particular movie was an “action-‐‑adventure movie” that tells you
something about the movie. There'ʹs probably some car chases,
probably some shooting, and so on. It tells you this even though
there is no universal definition that we'ʹve agreed to follow, and that
an action-‐‑adventure movie must contain at least three car chases, at
least 45 bullets must be shot, and ….
v So, “epic” is just a label we apply to a large story. Calling a story an
epic can sometimes convey additional meaning. Suppose you ask me
if I had time yesterday to write the user stories about the monthly
reporting part of the system. “Yes,” I reply, “but they are mostly
epics.” That tells you that while I did write them, I didn'ʹt get the
chance to break most of them down into stories that are probably
small enough to implement directly.
hNp://www.mountaingoatsoftware.com/blog/stories-‐‑epics-‐‑and-‐‑themes
58. Themes
We could put a rubber band around that
group of stories I wrote about monthly
reporting and we'ʹd call that a “theme.”
Sometimes it'ʹs helpful to think about a group
of stories so we have a term for that. Sticking
with the movie analogy above, in my DVD
rack I have filed the James Bond movies
together. They are a theme or grouping.
hNp://www.mountaingoatsoftware.com/blog/stories-‐‑epics-‐‑and-‐‑themes
62. Scenarios
v A usage scenario, or scenario for short, describes a
real-‐‑world example of how one or more people or
organizations interact with a system.
v They describe the steps, events, and/or actions
which occur during the interaction.
v Usage scenarios can be very detailed, indicating
exactly how someone works with the user interface,
or reasonably high-‐‑level describing the critical
business actions but not the indicating how they’re
performed.
63. Scenarios, User Case, User Story
Use Case:
Customer walks to the restaurant
Customer enters the restaurant
Customer finds a seat at the bar
Customer scans the menu
Customer selects a beer
Customer orders selected beer
Bartender takes order
Bartender pours beer
Bartender delivers beer
User drinks beer
User pays for beer
User Story:
A user wants to find a bar, to drink a
beer.
hNp://www.cloudforestdesign.com/2011/04/25/introduction-‐‑user-‐‑stories-‐‑user-‐‑personas-‐‑use-‐‑cases-‐‑whats-‐‑the-‐‑difference/
Scenario:
Josh is a 30 something mid-‐‑level
manager for an ad agency, metro-‐‑
sexual and beer aficionado. He likes to
try new and exotic beers in trendy
locations. He also enjoys using a
variety of social apps on his smart
phone. He reads a review on Yelp of a
new burger & beer joint downtown
with over 100 beers on tap, and decides
to go walk over after work and check it
out.
69. Roles, Ceremonies and Artifacts
• Scrum Team is small
(5-‐‑9), cross-‐‑
functional team
members from Dev,
UX, QA (excluding
Product Owner) to
ship complete
feature(s) end to end
• Scrum Master is the
servant leader
responsible for
supporting team
• Product Owner
owns Product
Backlog and sets
appropriate priority
for team to act upon
Roles
Product
Owner
Scrum Master
Scrum Team
Ceremonies
Sprint Planning
Meeting
Daily Stand-‐‑
ups
Backlog
Grooming
Product Demo
Sprint
Retrospective
Artifacts
Product
Backlog
Sprint Backlog
Increment
Release Burn-‐‑
down Chart
Sprint Burn-‐‑
down Chart
79. Product Owner
The product owner has responsibility for deciding what work will be done. This is the single individual
who is responsible for bringing forward the most valuable product possible by the desired date. The
product owner does this by managing the flow of work to 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 entire Scrum team is responsible
for being as productive as possible, for improving its practices, for asking the right questions, for helping
the product owner.
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 charged by the organization to
"ʺget this product out"ʺ and is 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
backlog, and progress against it, is kept visible.
The product owner, by choosing what the development team should do next and what to defer, makes the
scope-‐‑versus-‐‑schedule decisions that should lead to the best possible product.
hNp://www.scrumalliance.org/why-‐‑scrum/core-‐‑scrum-‐‑values-‐‑
80.
81. Old School Vs. New School
Old School
New School
Several roles bring
product to life
One role is responsible
Detached from
development teams
Member of scrum teams
Extensive work up-‐‑front
Minimum work up-‐‑front
Up-‐‑front product
discovery
Continuous product
discovery
Late customer feedback
Early and frequent customer
feedback
Agile Product Management with Scrum – Roman Pichler
82. Responsibilities Affected
You Used to do This
Now do This
Write an exhaustive PRD
Write user stories and maintain a
backlog
Strive to get it right the first time
Use experimentation as a
competitive advantage
Innovate and differentiate within
the confines of Product
Management
Leverage the creativity of your
entire cross-‐‑functional team to
innovate and differentiate
Have large amounts of time
between input and delivery,
watching market changes
without the ability to change
course
Be involved on a daily basis to
maximize the value delivered
83. Responsibilities -‐‑ continued
Always do This
Because…
Understand and communicate
Market Requirements
Helps ensure alignment
Have a clear customer value
proposition and metrics
Enables experimentation as a
competitive advantage
Seek and find Early Release
Opportunities
Provides rich learning
environment, early feedback, less
guesswork
84.
85. Top 5 ways POs can support your team
Share the product backlog for feedback from the team a
few days before sprint planning
Collaborate with the team to produce a great product
through product backlog management and delivery
ANend the daily stand-‐‑up
Come to planning meetings prepared
Provide a longer-‐‑term view of product vision, roadmap,
and goals that is negotiable in how it is delivered
86. Top 5 PM/PO behaviors to reconsider
The whole list is “must have”, by the target
release date
Product backlog isn’t ready for the team to plan
with
Not able to describe context and assumptions for
product backlog items
Not involving the team in backlog management
Not knowing your market
87. Product Owner Anti-‐‑PaNerns
Trying to reprioritize the work that team has commiNed to
in a sprint
Trying to unilaterally add or remove content of a Sprint
backlog after the team has commiNed to its delivery
Dictating, or trying to overrule, the estimates that a team
provides
Interfering with the Development Team’s ability to deliver
on their Sprint commitments
Deferring business decisions to the development teams
Expecting the development team to plan beyond one
iteration
hNp://agile.dzone.com/articles/product-‐‑ownership-‐‑practice
88. Common Product Owner Traps
The Underpowered Product Owner
The Overpowered Product Owner
The Partial Product Owner
The Distant Product Owner
The Proxy Product Owner
The Product Owner CommiNee
hNp://www.scrumalliance.org/community/articles/2010/april/common-‐‑product-‐‑owner-‐‑traps
89. Potential Product Owner Pitfalls
Product Backlog doesn’t exist
Product Backlog not visible to The Team
Never-‐‑ending stories
Stories too big
Product Owner without power or domain knowledge
More than 1 Product Owner
Product Backlog not maintained
Product Owner surprised at Sprint Demo
Product Owner not prioritizing
Product Owner being a boNleneck