Product Ownership Basics

1. AGILE EDUCATION
Product Ownership Basics

2. Topics
• Product Vision
• Product Roadmap
• Product Backlog
• User Stories
• Discovering User Stories
• Themes, Epics, User Stories
• User Stories in Lean Discovery
• Acceptance Criteria
• Tasks
• Gherkin

3. Product Owner
• Inward: Spending time with the team to implement
features.
• Current and upcoming sprint.
• Outward: Spending time with the stakeholders to
understand their needs.
• What are we solving?
• Refinement: Focus on the backlog (or roadmap) to ensure
it reflects the priority.
• Decompose and refine.
• INVEST

4. Product Vision
• What’s the over arching goal for the product?
• Who are the target users?
• What needs will the product address?
• What’s critical to the success of the product?
• What product is it?
• What makes the product special (selling points)?
• How does it compare to other products in the market?
• What positive change will the product bring?
• How will the product help the company?

5. Product Vision
• Description of the customer needs, necessary product
attributes.
• Clear: easy to understand and create alignment.
• High level: provide guidance yet leave room for
creativity.
• Concise: critical information for the success of the
product.

6. Product Vision
• Think elevator pitch.
• Motivation behind the product.
• NOT a plan.
• For (target customer), who has (customer need), (product
name) is a (market category) that (key benefit). Unlike
(competition), the product (unique differentiator).
The vision will guide your decisions!

7. Product Roadmap
• Who is your audience?
• Internal?
• External?
• What are your goals?
• What really matters?
• What’s your timeline?
• Date vs. Goal?
• Let the goal or timeline drive your features.

8. Product Roadmap
• Tells a story.
• Convincing
• Realistic
• Guides product vision execution.
• Aligns and communicates.
• Internal and external stakeholders.

9. Product Roadmap
• Step back and research.
• Evenly focused.
• Short-term tactics.
• Long-term goals.
• Inspect, adapt, communicate.
Tool — not a static document!

10. Product Backlog
What is NOT a Backlog?
• Business Requirements Document (BRD).
• A description of every item with same level of detail.

11. Product Backlog
What is a Backlog?
• List of features that contribute to the goal.
• If something no longer contributes to the goal, remove
it.
• If something new is discovered, add it.
• What contributes to the goal?
• Necessary.
• Sufficient.

12. Product Backlog
Why display the Product Backlog?
• Provide the big picture.
• Describe the primary objectives.
• Describe the key features.
• Communicate priority.
Help everyone understand the value and impact!

13. User Stories
• Why: promote agile values -- collaboration and just in time
definition.
• What: descriptions of a feature from the end users point of
view.
• Who: PO*, stakeholders, team members can write user
stories.
• When: throughout the life of the project/product.
• How: add conditions (acceptance criteria) and/or
boundaries (gherkin).

14. User Stories
• Who: As a <type of user>,
• What: I want <a goal or objective>
• Why: so that <a reason>.

15. User Stories: INVEST
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

16. User Stories (Example)
• As an online shopper, I want to add items to my online
cart so that I can purchase the items in my cart.

17. Discovering User Stories
• What will the user most likely want to do next?
• What mistakes could the user make?
• What could confuse the user?
• What additional information could the user need?

18. Discovering User Stories
• Epics
• At the feature level.
• Big and sketchy story.
• Break down into multiple stories.
• Themes
• Collection of related stories/epics.

19. Themes, Epics, User Stories (Example)
• Theme: Course Registration.
• Epic: As an Employee, I want to register for a course so
that I can get certified.
• Stories:
• As an Employee, I want to search for courses by
various fields…
• As an Employee, I want to review cost comparisons for
different courses…
• As an Employee, I want to view an outline for a
course…

20. User Stories in Lean Discovery
• Testable Hypothesis: We believe that
• Doing (this)
• For (these users)
• Will achieve (this outcome)

21. Acceptance Criteria
What is Acceptance Criteria?
• Conditions that the user story must meet for it to be
accepted as complete.
• Provides the PO the opportunity to describe to the
development team the minimal function (or
nonfunctional) requirements for the story.

22. Acceptance Criteria
What does Acceptance Criteria do?
• Help the PO answer what he/she needs in order for the
feature to provide value or eliminate risk.
• Help the team gain a shared understanding.
• Remove ambiguity and assumptions.
• Help team derive tests.

23. Acceptance Criteria
How to write good Acceptance Criteria?
• State intent not solution.
• Choose an account vs choose an account from drop
down.
• Independent from implementation (phrasing of web,
mobile, voice etc should be similar.
• Relatively high level (no need for granular details)

24. Acceptance Criteria (Example)
• Story: As an Employee, I want to search for courses by
various fields so that I can decide which course to sign up
for.
• User can search by name, category, cost, location,
instructor.
• User can perform a wildcard search
• User can sort results by any search criteria
• User can click on search criterion for more in-depth
analysis.

25. Tasks (Example)
• Story: As an Employee, I want to search for courses by
various fields so that I can decide which course to sign up
for.
• Code basic search screen – Owner, estimated hours.
• Code results screen…
• Write automated tests…
• Write SQL to query DB for search results…

26. Tasks: SMART
• Specific
• Measurable
• Achievable
• Relevant
• Time boxed

27. Gherkin
• Testable Requirements
• Specification by Example
• Executable Specifications
• Automated Acceptance Tests
• Behavior Driven Development

28. Gherkin
• Business readable, domain specific language.
• Connects human concept of cause and effect to software.
• Concept of input, process, output.
• Can be interrelated by automation tools to drive
acceptance tests.

29. Gherkin
• Given: you and your condition (input).
• When: what you do (process).
• Then: what you see (output).

30. Gherkin (Example)
Story: As an Employee, I want to review the various
discounts available so that I can pay for a reduced ticket
price for the course I selected.
• Given: I am purchasing a ticket to CSPO Course and I am
a Scrum Alliance member.
• When: I view my ticket prices
• Then: I see the discounted rate of $1,000

31. Gherkin (Example)
Story: As an Employee, I want to review the various
discounts available so that I can pay for a reduced ticket
price for the course I selected.
• Given: I am purchasing a ticket for CSPO course and I am
a “<membership type>”.
• When I view my ticket price
• Then I see the discounted “<ticket price>”.
Membership Type Ticket Price
Agile Alliance Member $1100
Scrum Alliance Member $1000
Nonmember $1200

32. THE END