This presentation describes the important techniques used in Product Backlog refinement and prioritization in Agile development. The various techniques described here are very useful for product managers, product owners, scrum masters, and agile teams.

1. Vikash Karuna
Product Backlog -
Refinement and Prioritization Techniques
Vikash Karuna
PMP, SAFe Agilist, CSP, CSPO, CSM, AWS/Azure/GCP Cloud, DevOps
January, 2019

2. Vikash Karuna
Session-1: Backlog Refinement
• Use Core Agile Concepts to Create a DEEP Backlog
• Write Effective User Stories & Acceptance Criteria
• Splitting, Thinning & Mapping User Stories
Session-2: Backlog Prioritization
• Factors considered in Prioritization
• Understand & Use Tools to Define & Measure Business Value
• Prioritization Techniques – Kano Model, Risk-Adjusted, Cost of Delay
OBJECTIVES

3. Vikash Karuna

4. Vikash Karuna
Horizon of Predictability
• Items that occur farther away in the time
horizon are less predictable
• Agile methods attempt to correlate
importance and effort with immediacy
• Items farther away
• Are less detailed
• Change more frequently
• Should consume less of the development
team’s time

5. Vikash Karuna
The “Agile Onion” Common Terms
• Strategy: Organizational plan for creating value
• Portfolio: Suite of products that execute the
strategy
• Product: A software system or set of inter-
related software systems that meet specific
customer needs
• Release: A development time-box used for
planning. Can encompass one or more
deployments to production
6 Steps of Agile Planning
Strategy
Portfolio
Product
Release
Sprint
Daily

6. Vikash Karuna
Detailed
Appropriately
-- Highest priority, more detail; lower priority, less.
Broken down into smaller stories for sprints/release
Emergent
-- Growing and evolving overtime;
Re-prioritized when items are added/deleted
Estimated
-- The product backlog items are estimated. The estimates are coarse-
grained and often expressed in story points.
Prioritized
-- Items that are slated for the next couple of sprints
Product Backlog – DEEP Model

7. Vikash Karuna
Typical Product Hierarchy
StrategyExecution
Theme
Initiative
Feature
Initiative
Feature Feature Feature
Epic
StoryStory Story
Epic Epic
Story Story

8. Vikash Karuna
Common Definitions
Theme
Initiative
Feature
Epic
Story
Program level work, with large focus areas that involves initiatives in
multiple business units; aligns to high-level organizational goal
Also known as Planview work id. Level of functionality that controls
funding decision. It may expand to more than one release
It is the minimum set of functionality that delivers perceived
value to a client. It needs to be contained to one release.
A large user story which can not be completed in a single
sprint. Epics are useful as placeholders for large requirements.
(You do not need to use Epics if they do not add value.)
The smallest element of the product backlog; can be completed
within 1 Sprint

9. Vikash Karuna
INVEST
Independent
-- Identify any dependencies, avoid introducing dependencies, combine to deliver
in a single sprint
Negotiable
-- stories are not contracts; need flexibility to adjust how much gets implemented;
a good story captures the essence, and just enough details.
Valuable
-- show the value to users, customers and stakeholders
Estimative
-- team needs enough details to estimate the size and effort and use it for planning
Small
-- small stories, sized appropriately for completion in a sprint (includes testing).
Large stories are harder to estimate and plan.
Testable
-- meets customer needs; understood by all team members, automate as much as
possible. Story must have acceptance criteria that can be use to test against

10. Vikash Karuna
Acceptance Criteria
User Story – Acceptance Criteria
**Supported by Exercise
What Who
WhyWhat is acceptance
criteria?
It is a set of criteria that
relates to testable
outcome and defines
terms to accept a work
Who writes acceptance
criteria?
It is written by Product
Owner or Business /
System Analyst
Why is acceptance criteria vital?
✓ Defines boundaries of a user story
✓ Confirms if a story is completed and working as intended
✓ Defines requirements criteria upfront from users view
✓ Documentation may include wireframes, business rules
✓ No last minute surprises at the end of sprint
✓ Ensures customer satisfaction
Sample Acceptance Criteria
➢ The rolling balance is displayed
➢ The rolling balance is calculated for each transaction
➢ The balance is displayed for every transaction for the full period of time transactions are available
➢ The balance is not displayed if a filter has been applied

11. Vikash Karuna
Patterns of Splitting User Stories
Splitting User Stories
User Stories need to be granular but not too abstract or too detailed
User Story Detailing Levels
Too Abstract
Often only at idea
level. Typically,
months to years time
of implementation
effort.
Summary
Also called as activity
level, it is still too
abstract. Typically, weeks
to months time of
implementation.
Meeting User Goals
Functional and is
considered useful level
of detailing. Typically
few days to one week of
implementation.
Sub-functions
More detailed and
explains individual
functions in detail.
Typically done in one
day time.
Too Detailed
Not profitable as detailing
takes long time. Typically,
steps in architectural layer
and is done within some
minutes to hours.

12. Vikash Karuna3.Orderedbyvalue
2. Chronological Order of user interaction
Story Mapping
Story mapping consists of ordering user stories along two independent dimensions. The User “map” arranges
user activities along the horizontal axis in rough order of priority (or “the order in which you would describe
activities to explain the behavior of the system”). Down the vertical axis, it represents increasing sophistication
of the implementation using epics and stories related to user-activities.
4. Carve out MVP
1. Backbone structure of user story map
Source: https://blog.easyagile.com/anatomy-of-an-agile-user-story-map-4ecb6a508d94

13. Vikash Karuna
Definition of Ready
Note- We recommend a checklist for definition of ready, and the same must be referred by dev team while verifying ‘Ready’ status
Ready Criteria
Story has been reviewed and estimated
by the team
Story is complete in prescribed format Acceptance criteria clear, agreed upon
Dependencies are listed PO has approved the story
Ready criteria is a set of
rules that a dev team adopts
as a guide for when a story
can legitimately be moved
from the product backlog
into a sprint
Ready defines the attributes
of the work packet (user
story) that need to be
understood before the dev
team begins actual work
Ready drives the readiness of
the work item to start the
work
Guidelines for Ready

14. Vikash Karuna
Putting it Together
PrepareStory
3C & 3W
INVEST
Size 1/10 to 1/6 of
Velocity
Definition of Ready
ApplySplittingPattern
Workflow Steps
Operations
Business Rule
Variations
Variation in Data
Interface Variations
Major Efforts
Simple / Complex
Defer Performance
Defer NFRs
Break out a Spike
EvaluatetheSplit
Revalidate
- INVEST
- Size 1/10 to 1/6 of
Velocity
- Definition of Ready
Try another split
pattern
CarveOutMVP
Story Mapping
FURPS+
Evaluate Value,
Learning, Risk
Mitigation etc.
Reprioritize

15. Vikash Karuna
Session-1: Backlog Refinement
✓ Use Core Agile Concepts to Create a DEEP Backlog
✓ Write Effective User Stories & Acceptance Criteria
✓ Splitting, Thinning & Mapping User Stories
Session-2: Backlog Prioritization
➢ Factors considered in Prioritization
➢ Understand & Use Tools to Define & Measure Business Value
➢ Prioritization Techniques – Kano Model, Risk-Adjusted, Cost of Delay
OBJECTIVES

16. Vikash Karuna
Product Backlog Prioritization
Create a big
picture of
priorities
Have clear “sequence
of delivery” of high
priority items
1
2
3
4
5
6
7
8
Product Backlog
Prioritize backlog
items based on key
relevant factors
1
2
3
4
5
6
7
8
Product Backlog
➢ Business Value
➢ Cost
➢ Risk (Business & Technical)
➢ Customer Satisfaction
➢ Complexity
➢ Frequency
➢ Time Criticality
Backlog Prioritization Considerations

17. Vikash Karuna
Factors Considered in Prioritization
1. Value – the financial value of having the features
2. Cost – the cost of developing and supporting features
3. New Knowledge – the amount and significance of learning and new
knowledge created by developing the features
4. Risk – the amount of risk removed by developing the features

18. Vikash Karuna
Risk
The four quadrants of the risk–value relationship Combining risk and value in prioritizing features

19. Vikash Karuna
Combining Value, Cost and Risk
ROI: Value vs. Cost Business Value vs. Technical Risk

20. Vikash Karuna
Estimating Business Value
The Product Owner is responsible for estimating Business Value for each Feature
Examples of Some Value Criteria are:
• Revenue Potential
• Demand from Customers
• Competitor Risk
• Alignment to Strategy
• Core Competency
• What else drives value for your product?
Potential Revenue?
Demand from Customers?
Expense Reduction?
Risk of Not Building?
Demand from New Prospects?
Aligns with Strategy?
Which Value Criteria Has More Weight?

21. Vikash Karuna
MoSCoW Method
Must Have
• Business goal/benefit is not accomplished without the story
• Product cannot go to production without it.
Should Have
• The purpose would be accomplished but an undesirable compromise or work
around would be needed
Could Have
• The purpose would be accomplished but the desired improvements would be lost
Want but Won’t Have
• Often called "gold plating“. A story which extends functionality beyond what is
necessary for the purpose or for which there is unclear benefit

22. Vikash Karuna
Kano Analysis – Requirement Curves
Unspoken,
Unexpected, Unknowns
Unspoken, Taken for
granted, Spoken if not
met
Spoken, Measurable
range of fulfillment
Threshold / Basic
Attributes

23. Vikash Karuna
Relative Weighting Prioritization
Source: https://www.mountaingoatsoftware.com/tools/relative-weighting#

24. Vikash Karuna
Risk-Adjusted Backlog
Capture inputs:
• Risks
• Probability of the risk (% or relative scale no.)
• Impact / Size of the loss ($ value or relative no.)
Plot the sum of the agreed risk
exposure values (impact x
probability) against iterations

25. Vikash Karuna
Cost of Delay Prioritization
• In a flow system job sequencing is key to optimize economy outcomes (ROI)
• Priorities based on lean economics, two things needed
▪ What is the cost of delay (CoD) in delivering value?
▪ What is the cost to implement the valuable thing?
• Use Weighted Shorted Job First (WSJF) to prioritize product backlog by
calculating the relative Cost of Delay (CoD) and Job Size (proxy to duration)
gives maximum economic benefits
▪ Taking an economic view
▪ Ignoring sunk costs
▪ Making financial choices continuously
▪ Using decision rules to decentralize decision-making and control
Donald G. Reinertsen

26. Vikash Karuna
Cost of Delay Prioritization – Weighted Shortest Job First

27. Vikash Karuna
Thank You !
Vikash Karuna