WORKSHOP

Writing
User Stories
contents
SECTION
user stories
1 what is a user story?
user story template
4
5
examples: user stories 6
user story checklist 7
why not tasks? 8

SECTION
writing acceptance criteria
2 what is acceptance criteria?
example: acceptance criteria
10
11
acceptance criteria checklist 13
WORKSHOP

What Is A
User Story?
definition: user story

A user story is a tool used in agile software development to capture the description of a software
feature from an end-user perspective. The user story describes the type of user, what they want and
why, A user story helps to create a simplified description of a requirement.

A user story often follows the following ‘equation’:

As a <type of user>, I want <some feature> so that <reason>

A simple example of this could be:

As an online shopper, I want to add an item to my cart, so that I can purchase it

user story template

WHO
As a <type of user>
are we building it for? Who is the user?

WHAT
I want <some goal or objective>
are we building? What is the intention?

WHY
are we building it? What is the value for the So that <benefit/value>
customer?
examples: user stories

As an internet banking customer

I want to see a rolling balance for my everyday accounts
So that I know the balance of my account after each transaction is applied

As an administrator
I want create other administrators
So that I can delegate tasks

As a marketer
I want create automated email campaigns
So that I can keep evaluators engaged
user story checklist

Keep them short

Keep them simple

Write from the perspective of the user

Make the value/benefit of the story clear - what is the reason for the story?

Describe one piece of functionality. If you have to write and break it into 2 stories

Write stories as a team

Use acceptance criteria to show a MVP

why not just use ‘tasks’?

user stories tasks

a user story = the WHAT the task = the HOW

user stories describe a piece of functionality from “what are the activities we need to perform in
the point of view of the user order to deliver outcomes (user stories)”

divided features into business processes tasks are individual pieces of work
WORKSHOP

Writing
Acceptance Criteria
definition: acceptance criteria

Acceptance criteria or ‘conditions of satisfaction’ provide a detailed scope of a user’s requirements.

They help the team to understand the value of the story and set expectations as to when a team
should consider something done.

Acceptance Criteria Goals:

- to clarify what the team should build before they start work
- To ensure everyone has a common understanding of the problem
- To help the team members know when the story is complete
- To help verify the story via automated tests
example: acceptance criteria

As an online banking customer, I want strong a strong password, so that my credit card information
is secure

Acceptance Criteria:

- The password must be at least 8 characters

- The password must contain at least 1 character from each of the following groups: lower case
alphabet, upper case alphabet, numeric, special characters (!, @, #, $, %, ^, &, *)
example: acceptance criteria

As a conference attendee, I want to be able to register online, so that registration is simple and
paperless

Acceptance Criteria:

- A user can not submit a form without filling out all of the mandatory fields
- Information from the form is stored in the registrations database
- Protection against spam is working
- Payment can be made via Paypal, Debit and Credit Card
- An acknowledgment email is sent to the attendee after submitting the form
acceptance criteria should include

Negative scenarios of the functionality

Functional and non-functional use cases

Performance concerns and guidelines

What system/feature intends to do

End-to-user flow

The impact of a user story to other features

UX concerns
acceptance criteria should NOT include
X Code review was done

X Non-blocker or major issues

X Performance testing performed

X Acceptance and functional testing done

why?
Your acceptance criteria should not include any of the above, because your team should already
have a clear understanding of what your Definition of Done (DoD) means. This could mean:

-
-
-
-
unit/integrated tested
ready for acceptance test
deployed on demo server
releasable
X
GETTING STARTED

Introduction to
Backlog Grooming
contents
SECTION
backlog grooming? SECTION backlog grooming using the
1 what is backlog grooming?
who should be involved in a grooming session?
4
5 3 story map
benefits of backlog grooming 6
example: car infotainment system 17
guidelines for effective backlog grooming 7
issues linked to an epic 18
difference b/w backlog grooming and issues without epics 19
sprint planning 8 prioritising on the story map I 20
prioritising on the story map II 21
refining the backlog - summary & estimation 22
SECTION
backlog grooming example: refining the backlog - sequencing 23

2 Apple TV
prioritising the backlog 11
breaking down big stories 24

refining 12
breaking epics down into user stories 13
estimating 14
repeat and refine 15
WORKSHOP

What is
Backlog Grooming?
what is backlog grooming?

Backlog grooming is when the Product Manager and their team review items on the backlog,
ensuring it only contains appropriate items ordered by priority, and that the items on the top of the
backlog are ready for delivery.

Some of the activities that occur during the refinement of the backlog include:

- Removing user stories that no longer appear relevant

- Creating new user stories in response to newly discovered needs
- Re-assessing the relative priority of stories
- Assigning estimates to stories which have yet to receive one
- Correcting estimates in light of newly discovered information
- Splitting user stories which are high priority but too large to fit in an upcoming iteration
- Looking more extensively into the total backlog to enable long-range technical and project
planning

Source: Agile Alliance

who should be involved in a grooming session?

Invitation to participate should be open to the whole

team (however, smaller groups work better)

Scrum Masters and Product Managers lead the

session

While it is desirable to have the whole development

team, this is not always feasible. At a minimum, the
lead developers should attend

There should be at least a few stakeholders involved

(keep numbers to a minimum to avoid distractions)
benefits of backlog grooming

Increases efficiency of the team by greatly reducing uncertainty and unknowns

Better refined stories are more accurately estimated, tested and implemented

Delays related to external dependencies and larger efforts are discovered sooner

Increases efficiency of the team due to increased shared knowledge and understanding of the product

Allows the team to maintain a sustainable, higher pace = greater team velocity

Reduces the time spent on Sprint Planning sessions

Increases the value of Sprint Planning meetings

guidelines for effective backlog grooming sessions

Set a goal for the session: send out a list of stories you want to groom ahead of time and ask
the team to review, coming to the meeting with any questions, tasks, hours etc. - the overarching
goal should be for all attendees to leave with a clear understanding of what is left for project
completion and the upcoming sprint goals

Keep the group small: involve the PM, their agile team and a few stakeholders. A smaller group
= more engagement and the less likely you are to get sidetracked.

Meet frequently: a good backlog grooming session leaves everyone feeling familiar with the
product backlog, gives them a clear understanding of the goals for the next sprint, and means
they can hit the ground running in the Sprint Planning meeting. Schedule grooming sessions
regularly, usually a few days before the Sprint Planning meeting
differences between backlog grooming
and sprint planning sessions

backlog grooming session sprint planning meeting

To maintain a healthy updated product To agree on a goal for the next sprint and the
purpose backlog to ensure time spent in sprint planning set of backlog items that will help the team to
is optimised achieve it

1) re-writing backlog items to be more 1) prioritising backlog item s

components expressive and deleting
CV obsolete ones 2) agreeing on the amount
CV of backlog items
2) Breaking up large stories in the sprint based on capacity

when? A few days prior to the sprint planning meeting At the beginning of every sprint
WORKSHOP

Backlog Grooming
Example: Apple TV
product backlog example: Apple TV
A product backlog for Apple TV at the beginning of a grooming session

As an iTunes user I want to redeem my gift card so that I can claim my credit ATV-121

As a user I want to find movies easily so that I save time browsing long lists ATV-111

As a user I want to be able to fast forward movies so that I skip scary parts of the film ATV-483

As a user I want to be able to save my favourite movies to a list so that I can watch them later ATV-345

As a user I want to use Paypal as my preferred payment method so that I feel safe about my transactions ATV-345
prioritising the backlog

The Product Manager knows that their users are having significant trouble searching for films, resulting in higher
churn. They decide to prioritise that backlog item for the upcoming sprint by moving it to the top of the list.

As a user I want to find movies easily so that I save time browsing long lists ATV-121

As an iTunes user I want to redeem my gift card so that I can claim my credit ATV-111

As a user I want to be able to fast forward movies so that I skip scary parts of the film ATV-483

As a user I want to be able to save my favourite movies to a list so that I can watch them later ATV-345

As a user I want to use Paypal as my preferred payment method so that I feel safe about my transactions ATV-345
refining the backlog
The Product Manager and Scrum Master begin to breakdown the prioritised backlog item. After discussions with
the team, they realise that this user story is going to be a large amount of work. They refine the user story into an
epic, to better illustrate the amount of work involved to achieve this objective

As a user I want to find movies easily so that I save time browsing long lists ATV-121

=
Search
breaking epics down into user stories
Using the epic, the team start to define various user stories that sit under the umbrella of that ‘Search’ epic. The
team prioritise the user stories by most immediate value to the customer. Value can be identified through
conversations with users, analytics on usage patterns, or another insight appropriate for your product.

Search

As a user I want to free text search so that I save time browsing long lists ATV-485

As a user I want to browse by genre so I can find movies I like quicker ATV-486

As a user I want to browse by most popular so I can find inspiration for films to watch ATV-487

As a user I want to browse by most popular by genre so I can find movies I like quicker ATV-488

As a user I want to browse by recent addition by genre so I find movies I haven’t watched before quicker ATV-489
estimating
Now that the user stories are ordered by priority, it is time for the team to allocate estimates to how long/how much
effort each particular story will take. This requires team members detailing requirements and acceptance criteria to
understand the scope of the work. Every team member is given the opportunity to put forward their estimate and
justification. The Product Manager will take the majority SP estimate or average, in this example the majority of the
team think the estimate should be 2.

As a user I want to free text search so that I save time browsing long lists ATV-485 2

2 1 2

3 2
repeat and refine
Continue going through the backlog with your team splitting stories and breaking out tasks. Work with the team to
prioritise backlog items, identify requirements, acceptance criteria and estimate work = a healthy backlog and an
enlightened team

As a user I want to free text search so that I save time browsing long lists Search ATV-485 2

As a user I want to browse by genre so I can find movies I like quicker Search ATV-486 3

As a user I want to browse by most popular so I can find inspiration for films to watch Search ATV-487 1

As a user I want to browse by most popular by genre so I can find movies I like quicker Search ATV-488 3

As a user I want to browse by recent addition by genre so I find movies …….. Search ATV-489 3
WORKSHOP

Backlog Grooming:
Using the Story Map
Example: Car
Infotainment System

This is an ‘unfiltered’ view of

a story map for a Car
Infotainment System. It has
not been split out into
Sprints or Versions.

This view allows us to see all

of the issues and Epics in a
team’s Agile Board.
Issues Linked to
an Epic

Highlighted on the left of

the Story Map, we see all of
the issues underneath their
associated Epics.

The Epics sit along the top

of the Story Map, and the
issues sit underneath.
Issues without
Epics

On the right, the open

‘Backlog’ panel displays all
of the issues that are not
associated with an Epic in a
Team’s Agile Board.

This view allows us to see all

of the issues associated with
a Team’s Agile Board
(whether they are
associated with an Epic or
not)
Prioritising the
Backlog on the
Story Map I

Stories are prioritised by

value to the user, with the
most valuable stories placed
at the top of the story map

We can prioritise issues on

the story map by simply
dragging and dropping
them into their designated
positions.
Prioritising the
Backlog on the
Story Map II

We can also prioritise issues

that are not associated with
Epics in the ‘Backlog’ Panel.

These issues should also be

prioritised by value to the
user, with the most valuable
items sitting at the top of
the ‘backlog’.

Simply drag and drop these

issues within the ‘Backlog’
panel into their designated
positions
Refining the
Backlog - Summary
& Estimation

The ability to inline edit the

estimate and summary of an
issues is simple inside the
story map. Simply click on
the summary or estimate
and begin to type.

Not having the pop the

‘Edit Issue’ dialogue, like in
the Jira Backlog, makes
backlog grooming in the
story map fast and
collaborative
Refining the
Backlog - Sequencing

The Story Map and Backlog

Panel can be split by Sprints
or Versions by selecting the
preferred Swimlane from
the dropdown at the top of
the Story Map.

Work is easily sequenced

into Sprints or Versions, by
dragging and dropping
issues into their designated
Swimlanes
Breaking Down Big Create New Issues
Stories Inside the Story Map
hover over the space you wish to create
a new issue. The ‘Add new or existing
issue’ dialogue will appear. Click new

Sometimes, a user story is

too big to complete as one
task. Breaking stories
down into a few smaller
stories is simple on the
backlog with the ‘Quick
Quick Create
Create’ feature. create tasks, stories or bugs and
inline edit the story summary without
ever having to leave the Story Map.
Hit enter to continue ‘quick creating’
issues
GETTING STARTED

Introduction to
Sprint Reviews
contents
SECTION introduction to sprint SECTION conducting sprint reviews in
1 reviews
what is a sprint review? 4 2 Easy Agile User Story Maps
benefits of sprint reviews 5 show ‘done’ issues 9
anatomy of a sprint review 6 inspect and adapt 10
guidelines for effective sprint backlog grooming and refinement 11
review meetings 7
WORKSHOP

Introduction
To Sprint Reviews?
what is a sprint review?
A sprint review meeting takes place at the conclusion of a sprint, and reviews all of the ‘Done’
issues for that period. The aim of the sprint review is to see whether the goal for the sprint was
achieved and to demonstrate potential shippable working product increments to the team.

Some of the activities that occur during the sprint review include:

- The Product Manager/Owner walks through the ‘Done’ items from the Product Backlog
- The Development team discusses what went well during the Sprint, the problems they ran into,
and how they were solved/could be solved
- The Development team demonstrates the work that they have “Done” and answer the teams
questions about the working increment
- The team collaborates on what to do next, so that the Sprint Review provides valuable input into
the subsequent Backlog Grooming and Sprint Planning sessions
- Review of the timeline, budget, potential capabilities for the next anticipated release of the
product
Source: scrum.org
benefits of sprint reviews

Increases stakeholder engagement (early and frequent feedback)

Maximises responsiveness to customers

Team building and collaboration

Updated and groomed backlog

Updated release plan

Increased cross-team product understanding

Increases the value of Sprint Planning meetings

anatomy of a sprint review

External Stakeholders Internal Stakeholders Scrum Team

V
Inputs Outputs
Sprint Review
Sprint Goal Overview of ‘Done’ issues and backlog Groomed product backlog
discussion
As an iTunes user I want to redeem my gift card so that I can claim my credit

Sprint Backlog
ATV-121
As an iTunes user I want to redeem my gift card so that I can claim my credit ATV-121

As a user I want to find movies easily so that I save time browsing long lists ATV-111
As a user I want to find movies easily so that I save time browsing long lists ATV-111

As a user I want to be able to fast forward movies so that I skip scary parts of the film ATV-145
As a user I want to be able to fast forward movies so that I skip scary parts of the film ATV-145
As an iTunes user I want to redeem my gift card so that I can claim my credit
ATV-121
As a user I want to be able to save my favourite movies to a list so that I can watch them later ATV-345
As a user I want to be able to save my favourite movies to a list so that I can watch them later ATV-345
As a user I want to find movies easily so that I save time browsing long lists ATV-111

As a user I want to use Paypal as my preferred payment method so that I feel safe about my transactions ATV-345
As a user I want to use Paypal as my preferred payment method so that I feel safe about my transactions ATV-345
As a user I want to be able to fast forward movies so that I skip scary parts of the film ATV-145

As a user I want to be able to save my favourite movies to a list so that I can watch them later ATV-345

Demonstration of potentially shippable

As a user I want to use Paypal as my preferred payment method so that I feel safe about my transactions ATV-345

product increment Updated release plan

Potentially shippable product increment
adapt

inspect

Source: Kenneth S. Rubin and Innolution

guidelines for effective sprint review meetings

Focus on ‘Done’ Issues: focus on acceptance criteria that had met the Definition of Done (DoD)

Meeting format: the meetings should be informal; not a reporting exercise, rather an
opportunity to get together and give feedback. Time box the meeting in accordance with the
following:

1 week sprint = 1 hour

2 week sprint = 2 hours
4 week sprint = 4 hours

Focus on the user: centre any demonstrations around a realistic user experience and business
value (not just proving functionality)
WORKSHOP

Conducting Sprint Reviews in

Easy Agile User Story Maps
show ‘Done’ issues

Showing ‘Done’ Issues

Filtering the story map to only
show ‘Done’ issues allows teams
to conduct their Sprint Review
Meetings quickly and
collaboratively inside of the Story
Map
inspect and adapt

Sprint Statistics
reviewing your teams forecasted sprint
statistics against the result of the actual
sprint helps teams track work
commitment, and ensure work continues
at a sustainable pace
backlog grooming and refinement

Inline Edit Story Point Estimates

after reviewing the forecasted sprint statistics
against the actuals, teams can inline edit and
update story point discrepancies for upcoming
stories, keeping the product backlog healthy
and updated
GETTING STARTED

How to Run
PI Planning with
Easy Agile Programs
contents
SECTION what is SECTION Digital PI Planning
1 PI Planning?
2 Easy Agile Programs overview
Setting Business Context
18

23
Overview 3

Benefits of PI Planning 5 Setting Product/Solution Vision 24

Anatomy of a PI Planning session 6 Team Breakouts: Setting Capacity 25

2 Day PI Planning Agenda 7 Team Breakouts: Scheduling Work 26

Who to involve in PI Planning 9 Team Breakouts: Cross-Team Planning 27

Difficulties of physical sessions 16 Draft Plan Review 28

Plan Review & Rework 29

GETTING STARTED

What is
PI Planning?
what is PI Planning?

PI Planning is a 2 day event which sees all members of an Agile Release Train (ART) come together
to plan out their next Program Increment.

Some of the activities that occur during a PI Planning session include:

- A senior executive/business owner describes the current state of the business

- Product Management presents the current program vision (typically represented by the next top
10 upcoming features)
- Product Owners and their teams, break estimate and plan work to achieve committed Features
- The teams identify and visualise cross-team dependencies and work to remove blockers
- A committed plan, in the shape of a Program Board is agreed upon by the conclusion of the
event
benefits of PI Planning

Establishing face-to-face communication across all team members and stakeholders

Building the social network the ART depends on

Aligning development to business goals with context of the business, vision and Team and
PI objectives

Identifying dependencies & fostering cross-team and cross-ART collaboration

Matching demand to capacity, eliminating excess Work In Progress (WIP)

Fast decision-making

Source: Scaled Agile Framework

anatomy of a PI Planning session

Business Owners, Product

Scrum Team
Manager + Release Train Engineer

Inputs Outputs

Business Context Committed PI Objectives

Gift card redemption
ATV-121

Search ATV-111

Roadmap & Vision Time Shift ATV-145

Favourites ATV-345

Payments & Billing ATV-345

Program Board
Top 10 Features of the
Program Backlog
Gift card redemption

CV CV
ATV-121

Search ATV-111

Time Shift ATV-145

Favourites ATV-345

Payments & Billing ATV-345

GETTING STARTED

2 Day PI Planning
Session Agenda
PI Planning agenda

DAY 1 AGENDA DAY 2 AGENDA

08:00 - 09:00 Business Context 08:00 - 09:00 Planning Adjustments

Product/Solution
09:00 - 10:30 09:00 - 11:00 Team Breakouts
Vision

Architecture Vision &

10:30 - 11:30
Development Practices 11:00 - 13:00 Final Plan Review & Lunch
11:30 - 13:00 Planning Context & Lunch
13:00 - 14:00 Program Risks

14:00 - 14:15 Confidence Vote

13:00 - 16:00 Team Breakouts
14:15 - ?? Plan Rework?

16:00 - 17:00 Draft Plan Review

Planning Retrospective & Moving
Management Review & Problem Forward
17:00 - 18:00
Solving

Source: Scaled Agile Framework

GETTING STARTED

Who is involved
in a PI Planning Session?
business owners
release train engineer
product manager
product owner
scrum master
development team
GETTING STARTED

Difficulties Running a
Physical PI Planning Session
difficulties running a physical session

Cost associated with geo-distributed organisations flying in employees for the 2 day event
(can be up to 5 times per year)

Difficulty in conveying information to non-participating team members after the event

(dependency visualisation in tools such as Jira, lack context of the physical Program Board

Ability to track the progression of the Program with geo-distributed team members after the
planning is finished
GETTING STARTED

Overview of
Easy Agile Programs for Jira
Programs
Breakdown

Program
Roadmap

Increment
Overview

Team
Planning Board
Programs
Breakdown

Program
Roadmap

Increment
Overview

Team
Planning Board
Programs
Breakdown

Program
Roadmap

Increment
Overview

Team
Planning Board
GETTING STARTED

Conducting PI Planning in
Easy Agile Programs for Jira
Setting Business
Context

Business Owners can share

a recorded video/
presentation with all
members of the ART by
linking to a Confluence
page in the Program details
section.

This presentation/recording
is not restricted to team
members being physically
present during planning,
and can be reflected on
throughout the entirety of
the planning session
Program Roadmap
Setting Product/
Solution Vision

Rather than presenting the

top 10 Features in a list-like
document, Program
Managers are able to
schedule their Jira Features
(Epics) onto a visual timeline
for the duration of an
Increment and share with
the entire ART

Program Roadmap
Team Breakouts:
Setting Capacity

Each team has their own

‘Team Planning Board’
which can be found in their
Project Sidebar.

Here, Product Owners and

their teams set the capacity
for each Sprint within their
Program Increment

Team Planning Board

Team Breakouts:
Scheduling Work

With the context of the

Feature Roadmap at the top
of their planning session,
teams are able to drag and
drop existing issues from
their backlog and schedule
them into their Sprints.

Teams can also create new

issues within the planning
board to support Feature
completion

Team Planning Board

Team Breakouts:
Cross Team Planning

Teams can add other teams

within a Program into their
Team Planning Board.

This visibility into cross-

team planning allows for
faster and easier
dependency discovery.

Simple drag and drop is

used to create and visualise
cross-team dependencies

Team Planning Board

Draft Plan
Review

The Increment Overview is a

digital representation of the
physical Program Board
created during the 2 day PI
Planning session.

Teams can easily present

their cross-team
dependencies to the ART in
this view, and unhealthy
dependencies are quickly
highlighted

Increment Overview
Plan Review
& Rework

The ability to inline edit

issue estimates and
summaries in real time,
makes reworking the plan
fast and simple.

All changes to issues in Easy

Agile Programs are
automatically reflected in
Jira

Team Planning Board

Backlog Prioritization Techniques
Common Agile Approaches to Prioritization of User Stories or Epics

Tom Taylor, Scrum Master & Pega Agilist

Backlog Prioritization
Scrum does not prescribe a specific method for prioritization
• But the PO is responsible for the prioritization of the Product Backlog
• In Scrum, a Sprint Backlog does not need to be prioritized as the Development Team commits to
delivering all of the User Stories. However, it is common for teams to maintain prioritization from
the Product Backlog

Prioritization techniques covered include:

• MoSCoW
• 20/20
• Risk-Value
• Weighted Shortest Job First (WSJF)

2
MoSCoW Technique
Approach
• Priorities are based on:
– Must Have, Should Have, Could Have, Won’t Have
– Replaces High/Medium/Low (since everything ends up High)
• Must Haves and possibly Should Haves help determine “Minimum Viable Product” (MVP)

Guidelines
• Option 1: Use group consensus to decide M, S, C, W priorities
• Option 2: Assign a point value to M, S, C, W. M should be highest, W should be lowest
– e.g.: M = 10, S = 7, C = 3, W = 0
• For every feature (User Story or Epic), the stakeholders assign individual points
• Points are totaled for each feature and prioritization is based on the highest scored items

3
MoSCoW – Point Value Example
Stakeholder Stakeholder Stakeholder Stakeholder Stakeholder Total
1 2 3 4 5

Scale
Feature 1 7 10 7 3 7 34

Feature 2 10 10 10 3 10 43

Feature 3 10 10 10 0 7 37
M 10
Feature 4 10 10 7 3 3 34
S 7
Feature 5 7 10 7 0 7 31
C 3
Feature 6 3 10 0 10 0 23
W 0
Feature 7 7 10 10 3 7 37

While it’s easy to see that Feature 2 is the top-ranked item and Feature 6 is the lowest, note that:

• Stakeholder 2 sees all features as equally important

• Stakeholder 4 cares exclusively about the least prioritized feature

• Features 3 & 7 are tied at 37 points – additional discussion needed. Same for 1 and 4

4
20/20 Technique
Approach
• A side-by-side assessment of 2 features at a time
• Like an eye exam asking “which is clearer - A or B?”, determine if A or B is the higher priority
• Also known as Force-Ranking or “Bubble Sorting”

Guidelines
• A quick, effective tool that can be used in teams, with internal stakeholders, or even customers
• Always start at the top of the list, only comparing 2 items at a time
• Forces collaboration – requires good communication and negotiation
– A facilitator can be useful

5
20/20 - Example
To be prioritized In Comparison Prioritized • Feature 2 is (so far) the top-most item
• Feature 1 is already lower priority than
Feature 2 Feature 2
• Feature 3 is also lower than Feature 2, and is
being compared to Feature 1
Feature 3 Feature 1
• After Feature 3 is ranked, Feature 4 starts
against Feature 2 and continues prioritization
Feature 4 continues

Feature 5
Feature 6
Feature 7

6
Risk / Value Technique
Approach
• Each feature is evaluated on its potential value, along with the perceived risk associated with
delivery
• In Scrum, attempt to start with high risk, high value first
• Or, alternatively consider delivering high value, low risk items for “quick wins”
• High risk, but low value items should be tabled or not considered part of MVP

Common Types of Project Risk

• Schedule Risk: “We may not be able to complete this feature in time”
• Cost Risk: “This feature may cost more than we expect”
• Functionality (Business) Risk: “This workflow may be all wrong”
• Technical Risk: “This may not perform at the level we need it to”

7
Risk/Value - Matrix
High Risk High Risk

High
Note that MoSCoW
Priorization can be ? 1
applied to the Low Value High Value
Risk/Value approache as
• Won’t-Have • Must-Have
well.

Risk
Low Risk Low Risk
3 2
Low Value High Value
• Should-Have • Must-Have
Low

• Could-Have • Should-Have

Low High
Adopted from: Agile Estimating & Planning by Mike Cohn
Value
Backlog Prioritization Techniques 8
Weighted Shortest Job First (WSJF)
Approach
• Applies data-driven prioritization based on Cost of Delay and Job Size

Cost of Delay looks at “What’s the pain of not having a feature available?” based on 3
considerations of
• Business Value: “What does this feature offer our ‘customers’ (end-users or internal)?”
• Time Criticality : “How urgently do we need this for use?”
• Risk-Reduction or Opportunity Enablement (RROE): “Is this a factor by which we boost delivery?”
– Competitive advantage, Speed, Quality, etc.

Job Size, or relative complexity, is the fourth factor

• Job Size is the proxy for how long delivery is expected to take

9
WSJF – Category Factors
Business Value Time Criticality Risk Reduction/ Opportunity Enabler
• Revenue Growth • Financial Targets • Market Penetration
• Business Strategy • Conferences • Speed, Quality, Delivery
• Cost-Savings – PegaWorld, SKO
• Architectural/Infrastructural
• Integration Investment
• Customer Satisfaction
• Acquisitions • Scalability

• System Retirement • Exploration

• Analyst Assessments • Partnerships

10
WSJF - Formula
WSJF is the Cost of Delay divided by Job Size

Cost of Delay
(Business Value + Time Criticality + RROE)
Job Size

• Each feature is assessed on a relative scale by the categories

• Start with the least-ranked feature and give it the lowest number
• Progress upwards through a single category before moving to the next one
• For Job Size, consult with team representatives

11
WSJF – Ranking Example
Feature A) Business B) Time C) RROE D) Cost of E) Job Size WSJF Score
Value Criticality Delay (D/E)
(A+B+C)
1 DevOps Investment
• New infrastructure
• Boosts internal productivity 1 2 2 5 2 2.5
• Extensive training needed

2 Mobile Application
• New technology – adds risk!
• Increase in mobile use 2 3 3 9 5 1.6
+ 2 points for risk
• Needed for competitive
advantage

3 New Quickstart
• Refactoring existing
functionality 3 1 1 5 1 5
• Must-have for conference in 6
months

12
WSJF – Ranking Example continued
1. Starting with Business Value, the least important
item is ranked as a 1. The next important
feature is given a 2, and so on Feature A) Business B) Time C) RROE D) Cost E) Job WSJF
Value Criticality of Delay Size Score
(A+B+C) (D/E)
2. Comparative ranking proceeds to Time
Criticality, working again from low to high New
Quickstart 3 1 1 5 1 5
3. Ranking continues to Risk
Reduction/Opportunity Enablement DevOps
Investment 1 2 2 5 2 2.5
4. Cost of Delay is the total of columns A, B and C
5. Job Size, like the other factors, is ranked Mobile
comparatively – with team representation Application 3 3 3 9 5 1.6
– Risk adds +2 points for Mobile Application
6. WSJF Rank is Cost of Delay is divided by the Job
Size

Per the example, the New Quickstart should be the highest prioritized item, followed by DevOps.
If Mobile Application is seen as a priority, then explore ways to mitigate the risks, lowering Job Size

13
WSJF – Do’s and Don’ts
Do’s
• Increase the weighting for uncertainty
• Keep focus on a single category at a time
• Involve representation from the team for Job Size estimate
• Retrospect on the rankings after delivery

Don’ts
× Assume actuals (# stories, point totals) for Job Size
× Think of Job Size in time units, think of complexity instead
× Be inflexible about the features. Like User Stories, ask if they can be split

14
Final Prioritization Tips
As a Product Owner, technical User Stories and Spikes will need to be prioritized, along with
End-User features.

Be careful to avoid these sometimes used prioritization “techniques”:

• Highest Paid Person in the Room
• Squeaky Wheel
• The Hot Potato (the hot topic of the week…or day…or hour…or minute…)

15