This document discusses best practices for managing large product backlogs in agile development organizations using the backlog management tool Hansoft. It covers prioritizing and estimating the backlog, defining user stories and acceptance criteria, assigning ownership, and structuring the backlog. Techniques include stack ranking, estimating in story points or days, using MoSCoW prioritization, and customizing backlog views and columns. The document includes examples and exercises for prioritizing features, estimating work, and defining user stories in Hansoft.

1. Agile Backlog Management
Practices in Hansoft to successfully handle large backlogs in product
development organizations
Hansoft is a backlog management tool you can download for free on www.hansoft.com
This presentation was made using version 9.2042

2. This presentation covers these pillars of backlog
management
▶ Prioritizing the backlog
▶ Estimating the backlog
▶ (Product) Ownership for just-in-time decision making
▶ Clarify and define acceptance criteria and user stories to understand underlying value
▶ Backlog structure
▶ Set (WIP) limits
Hands on / Features Covered
▶ Finding the backlogs
▶ Basic prioritization and estimation
▶ Delegation and access to backlogs
▶ Defining new user stories and definition of done

3. Iterative projects:
E.g. SCRUM Product Backlog
Stage/Gate/Waterfallproject:
E.g. Work Breakdown Structure (WBS)
Flows
What is a backlog?
Icebox Cool Warm Hot
Readiness backlog
The backlog:
Understand WHAT we should do
The plan:
Understand How and WHEN we
will do it

4. User
StoryGreat
Idea
Great
Idea
The Sprint
Backlog
2-4 week sprints
Sprint
Planning
Meeting
Daily
Standup
Finished
Work
Demo
Retro-
spective
Input from team,
stakeholders,
customers, managers
Product
Owner
SCRUM
Master
The product and sprint backlog in SCRUM

5. Program/product
Product roadmaps and release plans
This is typically a
‘Product Backlog’ in Hansoft
Team 3
Not yet selected Analysis Implementing
Successful backlog management is at the core of scaling agile
Portfolio
High level business epics
across all products
This is typically a
’Portfolio Project’ in Hansoft
Team 2
Increment 1
Linked to item
Team 1Team/project
Team backlogs and detailed implementation
schedules.
This is typically sub-projects in the planning
view in Hansoft
Commitment
Note: This is an
example and every
organization is
different. This is
why Hansoft is
highly flexible to
adapt to your
backlog needs.

6. Other types of backlogs
1) Bug Backlog
-Inflow not as easy to control
2) Portfolio Backlog
-Higher level items. Are we even working on the right product?
3) Individual backlogs
-Todo lists and similar
6

7. Example of the development of a backlog
Rough plan
Release1Release2Release3
Sprint 1
Sprint 2
Detailed plan During the project
Sprint 3
Sprint 4
S1 ended
S2
Scope
out?
Seeforexample:https://www.slideshare.net/wasitova/product-backlog-management
S3
S4

8. Why backlogs become fat
1) Hoarding: Backlogs tend to grow over
time
2) There is a risk of everything becoming
high priority
3) Lack of clear ownership
4) Multitasking: There are simply too
many things the teams want to do at
once
5) Time consuming discussions on low
value items
6) Something of high prio for one person
is low prio for another
8

9. Prioritization

10. What is your approach to prioritization?
Lightweight
approaches
Example: First in, first out
Beauracratic
approaches
Complicated and long
analysis phases to
develop business cases
etc.
Random
Example: Ad hoc, gut feeling
Systematic
Example: Highly based on data
Here?

11. The start is often an unordered backlog
This is a product
backlog item, “PBI”
that would add
value to the
business if
delivered.

12. … and stack rank it:
There can only be one number 1
This is a highly efficient way to
ensure that not everything
becomes ‘Very High Priority’.
Use ‘Show rank in list’ to see this
priority in Hansoft.
Stack ranking is done in the
priority view.

13. Add a ”business value” proxy
Estimating business
value to a single number
is difficult but common.
Add any custom column
in Hansoft to represent
this.

14. … maybe add some categories
The default Product Backlog priority column consist of 5 levels of priority.
This can be easily changed to any other column that has the type ‘Drop list single choice’
by main managers.

15. Example of another categorization: MoSCoW
Meaning Description
MUST Describes a requirement that must be satisfied in the final
solution for the solution to be considered a success.
SHOULD Represents a high-priority item that should be included in the
solution if it is possible. This is often a critical requirement
but one which can be satisfied in other ways if strictly
necessary.
COULD Describes a requirement which is considered desirable but
not necessary. This will be included if time and resources
permit.
WON'T Represents a requirement that stakeholders have agreed will
not be implemented in a given release, but may be
considered for the future. (note: occasionally the word
"Would" is substituted for "Won't" to give a clearer
understanding of this choice).Source: http://en.wikipedia.org/wiki/MoSCoW_method
This is just a custom column of type drop list single choice
that has been set to be the product backlog priority.

16. The Kano Model is useful to ensure that there is a mix of features being
prioritized
Learn more: http://en.wikipedia.org/wiki/Kano_model
Dissatisfied
Satisfied
Not implemented Fully implemented
Delighters, attractive features
With this, the client will get paramount satisfaction
but might not expect
Over time, a delightful feature
will become a basic need.

17. Eisenhower’s important/urgent principle
Source: http://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method
Use shift to sort on multiple
columns

18. Category - Pareto Analysis
1) Typical applications:
● Only allow 20 % to be of high priority
● We can complete 80 % of the tasks in 20 % time - let’s prioritize the
smallest 80 %
80 % 20 %

19. In the sprint plan, prioritise by technical dependencies
1
2 3
4 5 6 7

20. Exercise: Prioritize
▶ Define a way to prioritise your backlog
▶ Make it visual in Hansoft (custom columns, views, reports,
dashboards etc.)
▶ Discussion: Would this make sense for you in your daily work? Does
it make sense to your colleagues?
20

21. Estimation

22. Common techniques
1) Story Points: An abstract way to estimate decoupling size
from time
-Very useful in understanding velocity based on true progress
-Can be easier for teams not used to do estimates
2) Estimated Days
-How many ideal days (without interruption) would it take to complete the feature
-Easy to understand for stakeholders
-Can be hours as well
22

23. Easier alternatives
1) T-shirt size
-XXS, XS, S, M, L, XL, XXL
-Small enough, Big, Too Big
2) #NoEstimates
-Iterate, don’t estimate
-Estimation is waste
23

24. More complicated alternatives
1) Cost of delay
-Give a monetary value on the cost if the backlog item is not delivered
2) Combining multiple columns
-Use different columns to estimate for example strategic value, technical complexity
reduction, usability improvement, cost of implementation etc.
-Use a function column to get an index value of the importance
24
WSJF =
𝑈𝑠𝑒𝑟 𝐵𝑢𝑠𝑖𝑛𝑒𝑠𝑠 𝑉𝑎𝑙𝑢𝑒+𝑇𝑖𝑚𝑒 𝐶𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦+𝑅𝑅𝑂𝐸 𝑉𝑎𝑙𝑢𝑒
𝐽𝑜𝑏 𝑆𝑖𝑧𝑒
RROE Value: Risk Reduction Opportunity Enablement Value

25. Low weight first
Pick the smallest with highest cost of delay first
Project Duration Cost of delay Weight = CoD /
Duration
1 1 10 10
2 3 3 1
3 10 1 1
1
2
3
3
2
1
Delay Cost
High weight first

26. Common pitfalls
1. Spending too much time to estimate items that are never
likely to be implemented within scope of project
2. Too much focus on estimate vs. actuals, rather than as soon
as possible or with sufficient quality.
3. Excessive time reporting bureaucracy
26

27. Exercise: Buy a feature!
1) List five current features that you would like to have (or we
make some up)
2) Give each feature a size estimate in story points: 1, 2, 3, 5, 8
or 13 points.
3) Each person has 3 story coins – now invest your coins in the
features you want and add it in a Hansoft backlog.
27

28. Backlog Ownership

29. Delegation
Delegation is a key aspect of good backlog
management
Do not delegate to everyone, use it to make
clear who is reponsible (team or person)
The Product Owner Role is the most
common solution
29

30. Exercise
Make it visible to everyone in the team who is the owner of each
section in the backlog.
30

31. Defining new user stories and definition of
done

32. Working with user stories
Definition of ready (INVEST):
1) Independent
2) Negotiable
3) Valuable
4) Estimable
5) Small enough
6) Testable
32
As a <type of user>, I want <some goal> so that <valuable reason>.

33. Why user stories?
1) User stories are the lowest level items in a product backlog
2) They are intended to be humanly readable and written so that
both developers and customers can understand what they
mean.
3) More importantly, they are the foundation of a good
discussion
33

34. User stories in Hansoft
1) Specific flag
2) Keep the item name short and add the details in the user story
field.
3) Examples of how to define acceptance criteria in the backlog.
34

35. Exercise: Work with User Stories
1. Add a couple of new user stories
2. Flag them as user stories and write the user story sentence in
the appropriate field
3. Add Acceptance Criteria as a separate column
4. Show the user story in the backlog list
35

36. Structuring the product backlog

37. Backlog Structures
▶ Presentation
▶ Dimensions in the backlog (actors, processes, structure)
▶ Walk through some example backlogs
▶ Hands on / Features Covered
▶ Customizing the product and sprint backlog
▶ Structuring a backlog

38. Organization
Process
ComponentType of work
Planning horizon
Goal
How do we generate
value for our users?

39. Useful features in Hansoft to structure the backlog
1) Hierarchy
2) Columns (custom once particularly)
3) Workflows and pipelines
4) Reports
5) User view presets
6) Different views (planning vs. backlog)
39

40. Component Backlog
On some level the component is typically
included in the structure of a backlog.
The main issue is that a user story typically
affects multiple components so it becomes
very difficult to manage.

41. Process Backlog
Giving the process priority in structure
means it is simple drag-and-drop to move
from one stage to another.
There are other mechanisms for capturing
the process that also connects with default
status

42. Organizational Backlog
Works well with delegation feature.
Usually the best starting point as backlogs
tend to be per team so it is easy to work
with.
One drawback can be to get higher level
understanding and managing
dependencies between teams.

43. The Goal Driven Backlog
The recommended way to break down a
backlog in most agile context
Gives very view overview and focus on
value driven work towards the
organization’s higher level goals
Might be difficult to manage ownership in
contexts with multiple product owners

44. Exercise
1) Build a backlog structure so that it is clear:
-Who is going to work on each item
-The process the item will follow to completion
-Where in the product the change will happen
2) Discuss: What do you find most relevant levels in the backlog
hierarchy?
44

45. Backlog Refinement Practices

46. Reduce Batch Size
Value Delivered
Time
Delivery of small fine grained
valuable work item
Delivery of all items at once

47. Exercise: Batch Size
Problem
Working with an outsourcing partner, requirements are sent off in
batches of 10 work items at the time with a fixed date for delivery.
1) Represent this in your project
2) Visualize the batch size
Discussion: What are key constraints that control batch size?
47

48. Constrain WIP
It is much easier to start work than it is to
finish it. By controlling how much Work-in-
Progress there is you can manage the
finish line.
48

49. Visualise WIP
1) Defined as number of items in the status In Progress at any
given time, create a report that clearly shows the current WIP
2) Right-click on a section in the backlog and select Create
Dashboard Chart
-Use “Status” as the dimension
-“Number of items” as the measure
49

50. How many items can a person manage?
1) A good rule of thumb come’s from Dunbar’s number:
50
150

51. What do we do when we reach the limit?
1. Block new demand
2. Remove low-value items from queue
3. Flexible requirements
4. Apply extra resources
5. Part-time resources for high variability tasks
6. Pull high-powered experts to emerging bottlenecks
7. Develop T-shaped people that are deep in one area and broad in many
8. Cross-train people in adjacent processes
9. Use upstream mix changes to regulate queue size
51

52. Establish Cadence and Synchronization
1) Waiting times becomes predictable
-Velocity helps understand and forecast capacity in sprint
2) Enables small batch sizes:
-Compare Product backlog vs. sprint backlog
3) Limits the accumulation of variance
4) Fast feedback is enabled
5) 2-4 week synchronized sprints are recommended in SCRUM
environments
52

53. Scenarios with different cadence

54. 6. Decentralized Control
1) Centralize control for problems that are infrequent, large, or
that have significant economies of scale.
2) The inefficiency of decentralization can cost less than than
the value of faster response time
54

55. Exercise: Decentralize dependency resolution
Problem
Two teams are having many dependencies between each other. They pull their
work from the same backlog in Hansoft.
Be creative and create a structure that would help in dependency resolution so
that it is easy:
- Send a signal through Hansoft on the items that have a dependency
- Add a report available to all project members with identified dependencies
55

56. Keep the product backlog in shape
Refining the product backlog is a job, it is not something that can
typically be done in the scope of a sprint planning meeting but is
done continuously through interaction and collaboration with the
Product Owner.
56

57. Allow for a process also in the backlog
1) There are several ways to capture a process:
-Separate the backlog (Inbox, Backlog)
-Setup workflows
-Add custom columns
57
Raw Refined Accepted Committed

58. Aging Backlog
1) Create a report that filters everything that has not been
updated in a year or more and is not in status Completion.
Discussion: Are these ideas still relevant?
58

59. Workflows
1) States
2) Transitions
3) Connecting item status to the workflow
4) Simple review workflow
59

60. Setup a backlog workflow
1) Set up a simple workflow for implementing backlog items
(Design, Implement, Test, Completed).
2) Make sure that only the testers can set an item to the
workflow status Completed
3) When an item reaches the workflow state Completed the
default status should automatically be set to Completed
4) Commit a few items from the backlog to the sprint
5) Tag a few stories in the sprint backlog to the workflow
60

61. Transport - Multiple Sources of Information
 One system with one backlog
 Setup projects with minimum need to duplicate information

62. Inventory - Keep More Information than Needed
 Allow teams to work in different ways
 Not everything has to be managed in Hansoft, items directly
related to customer value to go into backlogs
 Tightly manage the number of columns

63. Unnecessary Movement - People having to move to
gain or access information
 Learn how to create reports and use find in Hansoft to find
relevant information
 Do not only use Hansoft for status, also for feedback as a
means to avoid meetings or to make them more efficient

64. Waiting - for data, late or wrong delivery
 Develop in parallel where possible – and integrate often to
validate
 Use CFD’s to manage work in progress to shorten lead times
and be able to better forecast delivery
 Hansoft is a real time system – utilize that to always stay up to
date on what work can get started

65. Over Production - Work that is not needed,
reinventing the wheel
 Share and learn good practices of how to use Hansoft
 Break down large, high prio, requirements to smaller before
starting to work on them to learn what work can be avoided
 Before using pipelines, think through if it would make you
more efficient or create work that is not needed.

66. Over Processing - Working more than necessary,
working on wrong release, unclear requirements
 Definition of Ready and Definition of Done is a good practice both
for hardware and software teams
 Tag work towards the same releases across hardware and
software
 Use allocation features to understand work load

67. Defects - Rewrite, redo, reschedule, rework, retest
etc.
 Use simple quality metrics in Hansoft: Are more bugs
departing or arriving the bug queue?
 Definition of ready and definition of done improves quality –
do not sacrifice quality!

68. Metrics

69. Why we need metrics?
69

70. Backlog Metrics
Presentation
▶ Agile Actionable Metrics – what is it?
▶ Quick intro to reports and dashboards
▶ Example Metrics
Hands on / Features Covered
▶ Backlog quality metrics
▶ Velocity metrics
▶ Capacity metrics
▶ Custom metrics

71. Numberofitems
Time
Todo
In progress
Done
Avg. Lead time
Queue
size
Linear
Process
Cumulative Flow Diagrams

72. Numberofitems
Time
Todo
In progress
Done
Monitoring queue
size is more
important than lead
time

73. Example from a more traditional project
Initiation Project Planning
Project
Execution
Project Closure
Time
Completed In progress Remaining Scope Scope Creep

74. Setup a simple CFD
1) Create a chart on a new page called CFD
2) Add the project backlog items as filter
3) Add Historical data and Status completion as dimensions
4) Add number of items as measure
74

75. Agile metrics for everyone
Important decision making happens everywhere in agile
organizations. This is why each team, function and
individual need access to relevant metrics to support the
decisions they are responsible for. Hansoft empowers everyone,
regardless of hierarchy, to track metrics and make better
decisions.
75
Metrics are relevant on all
levels

76. The Dashboards Section
76
A page is a
collection of
charts
A chart or item
view
Use filters for
each chart or
item view
Dimensions as
legend or “Y-
axis”
Measures are
the datapoints
Control layout,
colors and
share

77. Example with Status
77

78. Filters can also be set on Measures
78

79. Visualise if high prio things are smaller
79

80. Can items fit into a sprint?
80

81. Is something happening?
81

82. Is the backlog prioritized?
82

83. How DEEP is your backlog?
Problem
As a Product Owner I want to identify if my backlog is DEEP
1) Setup a quality page in dashboards to visualize the quality of
your backlog. For example:
-Is every user story prioritized?
-How many items are of highest priority?
-How many of the items are estimated?
-When were items last updated?
83

84. The Burndown Chart
84

85. Forcasting Setting
On historical data dimension you have
forecasting settings:
Show a calculated forecast made by
Hansoft
Work with a custom forecast
85

86. Will we hit our milestone?
86

87. How is each team tracking towards completion?
87

88. Establish cadence
1) Setup a schedule with several synchronized sprints
2) Create a burndown chart showing the progress over several
of these sprints
3) Clone the chart
4) Show a “best case” forecast in one chart and a “worst case”
in the other.
88

89. Understanding Velocity over Time
89

90. Resource Efficiency vs. Flow Efficiency
90
ResourceEfficiency
Flow Efficiency
Strategy to increase
utilization
Strategy to fulfill
needs asap
Source: Niklas Modig and Håkan Forss

91. Resource Efficiency vs. Flow Efficiency
91
ResourceEfficiency
Flow Efficiency
Strategy to increase
utilization
Strategy to fulfill
needs asap
Source: Niklas Modig and Håkan Forss
Lean Path

92. Work In Progress
92

93. Release Size
93

94. Allocation metrics
94

95. Resource Allocation
Show Individual Allocation
Allocation View
95

96. Summary
1) Backlog quality metrics:
-Priortization charts
-Estimation charts
2) Velocity Metrics
-Sprint and release burndowns
-Completed items per sprint
3) Capacity Metrics
-Work in progress and batch size
-Allocation metrics and views
96

97. Real Backlog Management
1) Identify your top 3 backlog management challenges within the
project in your project group
2) Here are a few questions to get you started:
-Is the backlog humanly readable?
-How big is the backlog in total?
-How much is WIP?
-Is the ownership clear?
-Are all columns being used and for what purpose?
97

98. Next steps
▶ Download and install Hansoft to try this yourself from
www.hansoft.com
▶ Contact support@hansoft.com if you have any questions.