Agile for product owners v12

1
Agile for
Product/Service Owners

3
Course Requirements
Prerequisite
• Prior to taking this training, you should have completed the following:
• Agile 101 Training
Intended Audience
• Product/Service Owner
• Business Analyst
• Service Analyst
• Any role involved in Requirement Elicitation and Management process

4
Agenda
Agile and Scrum Flow – A Recap
Agile for Product/Service Owners2
Introduction to Product/Service Backloga
Writing Good User Storiesb
Writing Testable Acceptance Criteriac
1
Backlog Refinement Techniquesd
Prioritization Techniquese
Release Planning and Metricsf
Working with the Customerg
Scrum in Large Organizationsh

5
What are Lean Principles? And How do we implement them in Agile
Lean Principles Implementation in Agile
Eliminate waste Retrospectives, Feedback loops at every iteration
Amplify learning Retrospectives, Feedback loops at every iteration
Decide as late as possible Iteration Planning every 2 weeks
Deliver as fast as possible Short Iterations
Empower the team Servant Leadership, Team Collaboration
Build integrity in Build Quality In: Continuous Testing & integration
See the whole Cross functional teams, breaking down Silos
Principles
Values
Process
Practices
(kata)

6
In Summary: Scrum is most common Agile Framework
• Each sprint has a fixed duration “time-box”
• Each sprint delivers working, fully tested code
• Only the team can do a pull from backlog
• Team cannot plan to exceed their capacity
• Team sync up on sprint goals during daily standup
• Core team size cannot be dynamic
• Team stays together for extended duration Scrum is lightweight yet, like rugby, needs rules to ensure
correct flow.
It is the responsibility of the Scrum Master to ensure
adherence to the agreed rules.
Scrum Values
Commitment, courage, focus, openness and respect

7
Agenda
Agile for Product/Service Owners
1
Introduction to Product/Service Backloga
2

8
Video #0: Product Owner Role
Agile Product Ownership in a nutshell
by
Henrik Kniberg

9
What is Role of Product/Service Owner?
Accountable for maximizing the value of a product/service, by incrementally managing
and expressing requirements for a product/service to the team
Key Responsibilities include the following:
Create Product/Service Vision and convey vision to the team
Manage and Refine Product/Service Backlog
Prioritize features according to market value
Drive Release Planning
Collaborate and Communicate with Stakeholders and End Users – Manage Expectations
Demonstrate Return on Investment (ROI)
Accept, reject or defer the “finished” work based on results

10
A Day in Life of Product/Service Owner
• Assist Team members to resolve issues or
provide clarification
• Review the implementation of each sprint
backlog item as early as possible to confirm
the results are as desired
• Refine Epics/User Stories for future
requirements
• Conduct Product/Service Backlog
Refinement sessions to prepare for next
sprint planning
• Explain the priority user
stories to team
• Answer questions to
clarify requirements or
resolve issues that affect
implementation or
estimation
• Ensure team provides
sprint commitment at the
end of Sprint Planning
session
Sprint Planning
During Sprint
• Attend the Daily Scrum meeting as
observer, wherever possible
Daily Scrum
• Reviews the user stories
completed during the
sprint
• Provide feedback on
implementation, if any
• Formally accepts or
rejects user stories
planned for the sprint
• May involve other
stakeholders as necessary
• Reviews release progress
Sprint Review
• Participate in sprint
retrospective, if team
desires
Sprint
Retrospective

11
Agenda
1
Introduction to Product/Service Backlog
2
a

12
Product/Service Backlog
High priority
Low priority
Prioritized list of all work items, in form of Theme, Epics/Features, and User Stories which are classified as:
New item, Tech Debt (shortcuts taken), Defect Debt (open defects) & Test Debt (pending test automation)
Fine-grained Backlog Items
ready for Future Sprints
i.e. smaller user stories
Medium-grained Backlog
Items for Current Release
Coarse-grained Backlog
items for Future Releases
• It is truly all things.
If a thing is in there it might get done. If it isn’t
there, then there is no chance that it will be
done.
• It represents opportunities, not commitments –
a list of “what we want to do.”
• Items may be estimated (preferable), but
estimates do not imply committed delivery.
• It has a single owner:
Team’s Product/Service Owner

13
Product/Service Backlog: Defines the “What”
• “Theme” Over arching business capability or long lived
business process e.g. Online banking
• “Epic”, Business or architectural goals to be realized by
the system or software. Can span multiple sprints in
order to complete. e.g. Online Payment
• “User Story” Meaningful unit of work that be completed
by a team within a sprint – typically one distinct function.
Should not span more than one sprint. e.g. Payment
through credit card

14
Product/Service Backlog: Three Primary Sources
1. Business Stakeholders
3. Other Stakeholders
Stories
Epics
• Other team
dependencies
• Other commitments
• Spikes/Research
2. Team Context
• Tech Debt (Refactoring)
• Maintenance
• Defect Debt
• Test Debt (Automation)
• Product Vision
• Business Requirements

16
User Story Map: Begin With End In Mind
• Release Planning
starts with User Story
Mapping
• Align stories as per
user activity (2nd line)–
helps with grouping
the features (1st line)
toward the activity
• High value items at
the top and low value
items at the bottom
• Stories
(Product/Service
Backlog) categorized
by Releases
(Release Backlog)
• Incrementally realize
the Product Goals
optionality
necessary
less
optional
more
optional
Release 1
Release 2
Release 3

17
User Story map Exercise
• Identify an Epic from your current engagement (1 per group)
• Create a user story map for 1 or 2 personas

19
Agenda
1
2
a

20
User Stories- Why and What
Why?
 Focus on value at a granular level
 Created specifically to link requirements
with users
 Encourages visualisation rather than
verbalisation
 Fundamental building block for any agile
delivery mechanism
 Facilitates early return on investment, and
feedback
 Demands consideration of vertical slicing +
emergent design
What?
 Method of capturing requirements that shifts focus
from writing to talking
 Typically written in the format: as a {type of user} I
want {some goal} so that {some value}
 Written by BAs/SAs with input from
Product/Service Owners, Tech Leads, Developers,
QA, Scrum Masters and/or other SMEs as defined
by Product Management.
 According to Mike Cohn, a User Story “is an
agreement to have a conversation in the future.”

21
User Story Guidelines: Ron Jeffries’ “Three Cs*”
*© Ron Jeffries
Card
Written on card/tool and may
annotate with notes
As a spouse
I want a clean garage
so that I can park my car
and not trip on my way
to the door.
Conversation
Details in conversation with
Product/Service Owner
What about the bikes?
Oh yeah – hang the bikes.
Confirmation
Acceptance criteria confirm
“correctness” of user story
Tools have been put away
Items are off the floor
Bikes have been hung

22
Card
• User Stories are typically written in the format:
As a {role} I want {some activity} so that {some value}
A role can be a user, device or other system.
As a policy holder,
I want the customer support specialist to
give a consistent, clear messages
so that I can resolve my issues without
needing additional support.
As a Web crawler,
I want a crawl constrained only to new URLs
in the URL dictionary
so that the crawling cycle can be completed
quickly

23
Conversation
Product/Service Owner, stakeholders, developers, and testers communicate continuously to
ensure maximum value delivered!
• Conversation spans all steps in story lifecycle
• Conversation provides shared context
• Conversation drives requirements via scenarios
• Conversation uncovers gaps in scenarios & NFRs
(non-functional requirements)
Conversation
Shared Context
STORY

24
Confirmation
As a consumer:
I always see current energy pricing reflected on my portal
so that I know that my energy usage costs are accurate
and reflect any utility pricing changes
Confirm using Acceptance Criteria:
• The current pricing is always used and the calculated numbers
are displayed correctly on the portal (see attachment for
format)
• The pricing and the calculated numbers are updated correctly
when the price changes
• The “current price” field itself is updated within the SLA time
• The info / error message appears when there is an error or
fault in the pricing (see attached approved error message for
format)
• Cover relevant aspects, including:
• System Behavior
• NFRs (non-functional requirements)
• Are mainly defined during Sprint Planning, but also
can be defined before (at Backlog Grooming
Sessions), or after Sprints
• Serve as a starting point for story acceptance tests

25
I N V E S T
Independent Negotiable Valuable Estimable Small Testable
- Make
stories as
independent
as possible
from each
other
- Start with a
brief
description
- Details
emerge in
discussion &
negotiations
- Users and
customers
perceive
value in the
deliverables
- Domain and
technical
knowledge
allow the
team to
provide
estimates
- A team can
finish one
story in a few
days, and
several in
every sprint
- Acceptance
(testing)
criteria and
technique are
specified
clearly
Summary: Invest in Writing Good User stories

26
Life Cycle of a User Story
Product/Service Owner PO + ARCH + LEAD PO + QA + LEAD PO + Team
writes epics that are
negotiable and has
relevant business value
Architect and Team Lead
negotiate with PO/ SO to
create vertical slices of
epics to shape small and
independent stories
QA ensures stories are
testable and estimable
with scenarios for each
user story
Additional story split along
scenarios and acceptance
criteria may occur
Team receives well
packaged user stories
Team negotiates user
stories with the
Team sizes story for
understanding and
provides estimate
Negotiable
Valuable
Independent
Small
Estimable
Testable

27
Definition of Done: Accepting User Stories
A User Story is accepted when it satisfies the Definition of Done (DoD) and is accepted by the
Developers and testers
stick to DoD, predefined
criteria for backlog items
DoD
STORY
STORY
STORY
STORY
STORY
Agile Team Product/Service Owner
Product/Service Owner reviews
Acceptance Criteria w.r.t. finished
work and accepts/rejects/defers
story

28
Agenda
1
2
a

29
So Where are the Details?
As a user, I can cancel a reservation so that I can get a refund
• Does the user get a full or partial refund?
• Is the refund to her credit card, or is it site credit?
• How far ahead must the reservation be cancelled?
• Is that the same for all hotels?
• For all site visitors? Can frequent travelers cancel later?
• Is a confirmation provided to the user?
• How?
Consider following story and possible questions about accepting that story:

30
Details as Conditions of Satisfaction
Product/Service Owner’s Conditions of Satisfaction can be added to a story.
These can be added as “acceptance tests” to ensure done-done.
As a hotel user, I can
cancel a reservation…. • Verify that a Premium Member can cancel the same
day without a fee.
• Verify that a non-premium member is charged a 10%
penalty for a same-day cancellation.
• Verify that an email confirmation is sent.
• Verify that the hotel is notified of any cancellations.

31
Exercise #2: Decompose Epic “Send Money Using Mobile Devices”
Activity:
• An Epic will be provided to each group
• Group needs to identify 3 user stories with acceptance criteria in 15 minutes
• Group will write user stories in a format specified in the template below:
• Each group will present 3 user stories
AS A…… I WANT…. SO THAT….. ACCEPTANCE CRITERIA
User A feature Business reason for doing it Conditions of satisfaction

32
Exercise #2: Decompose Epic into User Stories from Story Map (Template)
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
Participate in user story grooming session to write 3 user stories from your Story Map
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:

33
Exercise #3: Decompose Epic “Send Money Using Mobile Devices” (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. I can use options for payment gateway
2. I can see hold on my credit/debit card
Dependencies
Risks
Non-functional Requirements
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
Dependencies
Risks
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
Dependencies
Risks
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff

34
Agenda
1
2
a

35
Backlog Refinement: User Story Form
• 2-3 sentences used to
describe intent of the
story
• Summarizes intent and
represents a more
detailed requirement,
whose details remain
to be determined
(which leads to…)
• Recurrent discussion
between the team,
customer,
Product/Service Owner,
and other stakeholders
• Attached to a user story
as notes (which solidify…)
• Represent the
conditions of
satisfaction
• Written as scenarios
Card Conversation Confirmation

36
Card
As a [role]
I want [feature]
so that [benefit]
Scenario 1: [scenario title]
• Given [initial context]
• When [event occurs]
• Then [ensure some outcomes]
Scenario 2: [another scenario title]
• Given [initial context]
• AND [another context]
• When [event occurs]
• Then [ensure some outcome]
• AND [ensure another outcome]
Confirmation (Acceptance Criteria)
Backlog Refinement: : BDD (Behavior Driven Development) Template

37
Backlog Refinement: Splitting (slicing) User Stories with AC’s (Scenarios)
As a [role]
I want [feature]
So that [value]
Acceptance Criteria
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
Notes: [discussion notes]
US.01
As a [role]
I want [feature]
So that [value]
Acceptance
Criteria
Scenario 3
Scenario 4
US.01.01
As a [role]
I want [feature]
So that [value]
Acceptance
Criteria
Scenario 5
US.01.02

38
Backlog Refinement: How to “INVEST”? How do we slice a story into smaller ones?
• Slice it just like the way you cut a cake to relish the flavors in all the layers:
• Slicing your story vertically allows you:
• Deliver complete business-driven functionality to the customer early and incrementally
• Adapt architecture tasks based on changes from the customer
• Easier to plan and to complete within a sprint
• Enable feedback after each slice is completed

39
Backlog Refinement: Decomposition Cheat Sheet
• Rule of thumb: get the most value with the minimum effort
• Choose the split that leads to the biggest difference in value.
• Choose the split that leads to the smallest difference in size
• Patterns for Decomposing Features into user stories
1. On operation boundaries
2. On business rules
3. On effort boundary
4. On complexity
5. On data types
6. On input methods
7. On requirement type
8. On workflow boundaries
9. On engineering activity
10. On architectural boundaries
- this is your last resort,
when nothing else works!
Here are examples of patterns for feature decomposition into vertically sliced user stories:
Please pre-load this cheat-sheet with sample user stories from your existing Product/Service
Backlog.
Put those sample stickies next to each decomposition pattern here!

40
Backlog Refinement: Feature Decomposition Examples
Pattern Original story Split stories
Identify operational boundaries I'd like to manipulate posts on wiki
 I'd like to edit a post
 I'd like to share a post
 I'd like to delete a post
Identify independent business rules I'd like to search for a post
 I'd like to find posts from a specific person
 I'd like to find posts sent or received in a specific date range
 I'd like to find posts pertaining to a certain topic
 I'd like to find posts linking to a certain post
Perform what-if analysis to account for
technical or scheduling dependencies and
identify an effort boundary
I'd like to see an up-to-date contact list in
chat window
 I'd like to see an up-to-date contact list in my chat window:
o need to poll server periodically
o When notifications are implemented, we can leverage API
Isolate the simple from the complex
I'd like to share knowledge and
information with others
 I'd like to quickly share mostly text and maybe a link, a-la Twitter
 I'd like to add embedded images and multimedia content to my posts
 I'd like to add references to external data to my post, updated on-the-fly
Handle various data types separately
whenever possible
I'd like to ignore updates I am not
interested in
 I'd like to ignore updates from a specific person
 I'd like to ignore updates in a specific community

41
Backlog Refinement: Feature Decomposition Examples (Continued)
Pattern Original story Split stories
Provide the user with different ways to
input data into the application
I'd like the application to
help me with the list of
users I'm sharing a post
with
 I'd like to be able to pick people from a list of contacts I'm most often in touch
with
 I'd like to be able to search for people in the corporate directory
 I'd like the application to auto-complete a person's name as I am typing it.
Separate functional and non-functional
requirements
I'd like to be able to attach
files to a post
 I'd like to be able to attach multiple files to a post. It's OK if I have to add each one
separately.
 I'd like an easy way to attach multiple files to a post. Multiple select, drag-and-
drop or any other form is acceptable so long as I don't have to add each file
separately.
Identify workflow boundaries
I'd like the system to assist
me in creating a post
 When I add a post title, I'd like the system to look for similar posts and give me an
option to comment or edit them instead so as to avoid effort duplication
 I'd like to link data from other posts into the post I am creating and have the
system update it automatically
Split out the research from the
implementation
I'd like to configure the
application to my own
taste
 As an engineer, I need a framework to handle user preferences so that I can make
certain aspects of the application configurable
 As a user, I'd like to be able to set user preferences in order to configure the
application the way I like it

42
What about Non Functional Requirements (NFR)?
• Non-Functional Requirements such as performance, robustness, scalability, usability, as well as
technical and compliance requirements are treated as constraints:
• Global Constraint:
• Applies to all functionalities of the application. E.g. Performance of the application, federal/state
regulatory requirements, etc.
• Should be considered during road mapping or early backlog refinement phase. Late discovery of
such requirement will impact the product success
• Should be part of “Definition of Done” (DoD)
• May exist as “Non-functional” story or requirement
• Local Constraint:
• Applies to some functionalities or stories within application. E.g. Constraint-The MasterCard
charge transaction shall not be more than five seconds
• Should be stated as Constraint and attached to the story

43
In Summary: Product/Service Backlog Refinement
• Gain understanding of Product/Service Backlog items and break down large items into smaller items
• Ensures all Product/Service Backlog items are sized
• Ensures Product/Service Backlog items are ordered to maximize product value over time
• Ensures 1.5 – 2 sprints worth of items at the top of the Product/Service Backlog are “Sprint Ready”
• Team looks further ahead and starts breaking down large items
• Team should expect to spend 5-10% of each sprint helping refine the stories for the next sprint
• Product/Service Owner removes any stories that have been towards the bottom of the
Product/Service Backlog and will never be worked on

44
Exercise #3: Refining User Stories with BDD template (GIVEN… WHEN… THEN…)
Activity:
• Regroup with same team members as for “Writing User Stories” exercise
• Group now needs to review user stories identified earlier
• Use INVEST criteria review and refining the user stories
• Apply the 10 slicing techniques we discussed just now
• If possible, use GIVEN…WHEN…THEN… style for acceptance criteria
• Group needs to present the refined user stories

45
Exercise #3: Refining User Stories with BDD template (GIVEN…WHEN…THEN…)
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
Participate in user story grooming session to refine user stories created earlier:
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:
Domain
Banking
Title Priority
High
Story
Points
<ignore>
Description
Acceptance Criteria
As A:
I want:
So That:

46
Exercise #3: Refining User Stories with BDD template (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Apple as gateway
WHEN user enters payment
THEN Process payment
2. GIVEN card WHEN Pay THEN hold
Dependencies
Risks
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Square as gateway
Dependencies
Risks
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. GIVEN PayPal as gateway
Dependencies
Risks
Teams Participated in user story grooming session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff

47
Agenda
1
2
a

48
Product/Service Backlog Management - Priority Drives the Planning
Iteration / Sprint
Release
Priority
High
Low
Roadmap
Value
Risk
Cost
Knowledge

49
How to Prioritize Stories: MoSCoW Principle as an option
MoSCoW
– Prioritizes stories in four categories
Must Have - Stories that must be included in the project delivery time-box for the project success
Should Have - Stories not critical but should be included if at all possible
Could Have - Less critical but nice to have stories
Won’t Have - Least critical and lowest payback items
• Appropriate mix of stories in each category can be implemented for a release/sprint
• Example 50% can be Must have, 30% Should have, 15% Could have and 5% Wont have

50
How to Prioritize Stories: Risk Analysis as the other option
High Risk
Low Value
High Risk
High Value
Low Risk
Low Value
Low Risk
High Value
Value
Risk
Low
High
High
Avoid Do first
Do Last Do second
Value
Risk
Low
High
High
To optimally prioritize feature it is important to consider both risk and value
Business Dimensions
 The desirability of the story to a broad base of users or customers
 The desirability of the story to a small number of important users or
customers
 The cohesiveness and ordering of the stories in order to deliver the
release end-goals
 Business seeks for advice from the technical team but if there is
disagreement, Business might still push for the feature
Technical Dimensions
 Technical Complexity
 Technical Feasibility
 The technical risk that the story cannot be completed as
desired
 The impact the story will have on other stories if
deferred (consider high risk story first)

51
Exercise #4: Prioritizing User Stories
Activity
• Group now needs to prioritize user stories identified earlier based on value and risk factors
• Group needs to present the prioritized user stories
• Present the prioritized Product/Service Backlog

52
Exercise #4: Prioritized User Stories (Example)
Domain
Banking
Title
Send Money
Using iPhone
Priority
High
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Apple as gateway
Dependencies
Risks
Domain
Banking
Title
Send Money
Using Android
Priority
Medium
Story
Points
?
Description
Acceptance Criteria
1. GIVEN Square as gateway
Dependencies
Risks
Domain
Banking
Title
Send Money
Using BB
Priority
Low
Story
Points
?
Description
Acceptance Criteria
1. GIVEN PayPal as gateway
Dependencies
Risks
Teams Participated in user story prioritization session to come up with something like this:
As A:
I want:
So That:
iPhone User
To send money
I can buy stuff
As A:
I want:
So That:
Android User
To send money
I can buy stuff
As A:
I want:
So That:
BlackBerry User
To send money
I can buy stuff
3 5 8

54
Agenda
1
2
a

55
Sizing Board: Teams Size the Stories from Story Map(s)
• Use modified Fibonacci sequence:
1, 2, 3, 5, 8, 13, 20
• Always triangulate with other stories – for
example, an 8 point story should take 4 times
longer than a 2 point story
• Stories should be of similar sizes, to increase
predictability while trying to reduce variability
at the same time, e.g. 3, 5, 8

56
Release Plan: Forecast, typically for Next Quarter
• Based on:
• Relative priority of backlog
items
• The size estimate given to
each backlog item
• Team velocity: baseline it
with Known Velocity Trends
• Release Plan is reflection of the
• Updated Continuously – at end
of every sprint at least

57
And How to Track Product progress?.. (1)
Scrum Task Boards, Burndown Charts & Cumulative Flow
• Allow to view Product Progress over time
• Track against Release/Project Scope line
• Allows Product/Service Owner & team to make course
correction, if significant deviation from Ideal trend line

58
And How to Track Product progress? ..(2)
Release/Project Progress Detail Report
• Allows to view progress at Epic level
• Help to prioritize the sprint and release scope based on priority of each Epic and remaining work
0 20 40 60 80 100 120 140 160
Epic 10
Epic 9
Epic 8
Epic 7
Epic 6
Epic 5
Epic 4
Epic 3
Epic 2
Epic 1
Story Points
Epic Completion
Completed Size Estimated Size

Agile for product owners v12

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Agile for product owners v12

Semelhante a Agile for product owners v12 (20)

Mais de Ravi Tadwalkar

Mais de Ravi Tadwalkar (20)

Último

Último (20)

Agile for product owners v12

Notas do Editor