Planning & Managing

a Product Backlog

Benjamin Day
Coach, Trainer, Author, Speaker, Architect

@benday | www.benday.com
 What is a Product Backlog?
Overview
Who is it for?
Prioritization
Velocity & Estimation
What makes a good backlog?
Azure DevOps Demos
Up Next:

What is the Product Backlog?

What is the Product Backlog?
What is it for?
 The vision for the product
What is the
The list of every feature that might ever be
Product Backlog? considered for the product
 Too much work
Resource Not enough people
Constrained
Not enough time
Two Ways to Address Being Resource Constrained

Easy Way vs Harder Way

Don’t make any prioritization Acknowledge you can’t do

decisions everything at once
Leave it up to the developers Make prioritization decisions
Spread your effort across a lot of Focus on what you need the most
different things
Blame the developers when they
- Deliver the wrong stuff
- Don’t deliver enough stuff
 Focus on what you need the most
Focus on what generates the most…
- Joy
- Benefit to humanity
Prioritization - Customer engagement
- Money to the business
- Other?

“Business value”
Scrum wants you to deliver
done, working software in
30 days or less.
Scrum wants you to focus.
Scrum wants you to deliver
the highest possible
business value.
Scrum wants you to deliver
SOMETHING.
Scrum wants needs you to
prioritize.
Not everything can be the
#1 top priority.
 You need to make decisions about what to do
first
Your backlog needs to be prioritized

Prioritization Goal:
- Always work on the top priority items first
- Most important items to the business
- The items that deliver the most business
value
The Product Backlog is the
prioritized list of everything
that might ever be
delivered in the product.
 Product Owner (PO) is responsible for the
backlog
It is not just a list of requirements to be
worked on
The Product It’s the PO’s vision for the product
Backlog
The PO needs to share his/her vision for the
product

The PO often needs to make a case for his/her

priorities
 Transparency
Core Values in Inspect
Scrum
Adapt
 Transparency
- Backlog should be shared with others
- Backlog should be understandable by others
- Backlog should show the priorities
- “Feedback-able”
Inspect
Sharing the Vision - Other people should be able to see &
understand the backlog
- Gather feedback
Adapt
- Change the backlog
- Add, change, and delete items
- Modify the priorities
Up Next:

Demo: Create a Backlog in Azure

DevOps
Demo

Connect to Azure DevOps web interface

Create a Product Backlog
Up Next:

Signs of a Good Product Backlog

Signs of a Good Product Backlog
 Prioritized
PBIs are human-readable
- What do you want to achieve?
- Not tasks

A Good Product My recommendation: “Understandable by my

non-technical father with minimal
Backlog explanation.”
PBIs are estimated

PBIs have acceptance criteria

Enough ‘Ready’ PBIs for 2 to 4 sprints
 It’s not there
There’s not enough

Signs of a Sub- It’s too technical

Optimal Product - “Implement SQL Server file storage changes
for big tables”
Backlog
It’s too Task-y
- “Fix Bug #123”
- “Write a stored procedure for payments”
Your Product Backlog
should tell a story.
 Bullet points that describe what should
happen

PBI: “Recent Payments Page”

Product Backlog Acceptance Criteria:

- “Should be visible only to Administrators”
Items have
- “Link to page should not be visible to non-
Acceptance admin users or users who are not
Criteria authenticated”
- “By default, sort by descending payment
date”
- “Any color scheme should be usable by
people with red/green colorblindness”
 Scrum Guide:
“…done by the Scrum Team within one Sprint”

What is a Estimated
‘Ready’ PBI?
Well-understood by the team so it can be
easily selected into a Sprint
Have clear acceptance criteria
Up Next:

Product Backlog Item

Estimation & Velocity
Product Backlog Item
Estimation & Velocity
 Each PBI has an estimated effort
Estimating
Story Point Estimation
Product Backlog
- Common estimation technique
Items (PBIs) - Not required by Scrum
https://app.pluralsight.com/library/courses/scrum-master-skills
 Not based on hours
Rough level of relative effort

Story Point Usually using modified Fibonacci Sequence

- 1, 2, 3, 5, 8, 13, 21, 40, 80, 120
Estimation
Team-based estimate for making the PBI
‘Done’
- Definition of Done (DoD)
“Why not estimate PBIs in
hours?”
Humans are awful at
estimating in hours.
Winston Churchill

“Democracy is the worst form

of government,
except for all the others.”

http://en.wikipedia.org/wiki/Winston_Churchill_as_historian#mediaviewer/File:Churchill_portrait_NYP_45063.jpg
Winston Churchill Benjamin Day

“[Story point estimation] is the

worst form of [estimation],
except for all the others.”

http://en.wikipedia.org/wiki/Winston_Churchill_as_historian#mediaviewer/File:Churchill_portrait_NYP_45063.jpg
 Metric
Velocity
How much the team delivered in one Sprint
Velocity & the Sprint

Velocity =
Total # of Story Points delivered to
DoD in a Sprint

Got #1, #2, & #3 done?

- 8 + 13 + 5 =26
- Velocity = 26
Got #1 & #3 done?
- Velocity = 13
Got nothing done?
- Velocity = 0
Since velocity is based on
what your team actually
managed to do in a sprint…
Velocity helps you estimate
based on real data.
Tip:
Track velocity over time to
establish your average
velocity
Up Next:

Demo:
Velocity Tracking & Forecasting in
Azure DevOps
Demo

Velocity Tracking in Azure DevOps

Forecasting in Azure DevOps
Up Next:

Demo:
Manage Backlog Complexity using
Portfolio Backlogs
Demo

Hierarchies of requirements
Portfolio Backlogs in Azure DevOps
Up Next:

Demo:
Features vs. Tags vs. Area Paths
Demo Grouping Requirements in Azure DevOps
Portfolio Backlogs
- Features & PBIs

Work Item Area Path

Work Item Tags
 Portfolio Backlog
- Features / Product Backlog Items
When to use Use it to manage delivery of a large feature
Portfolio Feature + the smaller PBIs
Backlogs? Does your “Feature” eventually ship?
- Yes à Portfolio Backlogs
- No à Probably Tags or Area Path
 Description: We need to be able to view our
real estate holdings owned globally with their
current estimated values.
PBIs:
- Import Holding Data from System X to Data
Feature: Warehouse
“Real Estate - Import Holding Data from System Y to Data
Warehouse
Holdings Report”
- Display Basic Ownership Data
- Sort by Ownership Currency ($, €, £, ¥, ₹)
- Convert Value to Another Currency
- Sort by Value in Ownership Currency
- Sort by Value in Converted Currency
 System.AreaPath
- Core field of all Work Items
- Work items can only have one Area Path
Two Options:
- {Functional Grouping}
- {Team Name} / {Functional Grouping}

Area Path When to use Area Path?

- Long-lived grouping
- The path does not indicate something that
will ship like a Feature or PBI
- You want to control / standardize what the
groupings are

I don’t use Area Path that often except for

denoting teams
 Free-form text attribute for a work item
Super flexible

Tags No enforcement of naming

- “Manufacturing”
- “Mfg”
- “Manuhfackchuring”
 Let’s say your team serves three internal
departments
- Marketing
- Legal
- Retail
Area Path
Track PBIs for each department
vs.
Tags Work is for one department?
- Area Path or Tags

Work is for multiple departments?

- Tags
Up Next:

Demo:
Bugs on the Backlog
Demo Are bugs allowed on the Product Backlog?
Bugs & PBIs?
Just PBIs?
Backlog settings
Disable backlog bugs
 Optional setting
“Bugs are managed with requirements”
Bugs on the - Default

Backlog Bugs are managed with tasks

Bugs are not managed on backlogs and boards
- My preference
 It causes misunderstandings about ‘Done’
Definition of Done (DoD) belongs to PBIs
Teams often get into trouble thinking that
Bugs have a different DoD than PBIs
$0.02:
Bugs are just a list of defects
No bugs on the - Bugs are often ‘triaged’ and end up being
backlog related

No bug gets fixed unless there’s a PBI

- Ideally, the PBI title describes the underlying
problem
- Otherwise, “Fix Bugs 123, 5432, and 3311”
Up Next:

Demo:
Delivery Plans
Demo Visualizing how your work is being
delivered
Delivery Plans in Azure DevOps
Dependencies
Milestones
 What is a Product Backlog?
Summary
Who is it for?
Prioritization
Velocity & Estimation
What makes a good backlog?
Azure DevOps Demos
Up Next:

Sprint Planning