Backlog Anil Kumar
Prioritization Vaddaboina
Why do we need Prioritization?
▪ Prioritization is required in day-to-day life as there will be limited time for some of the
items/actions needed to execute.
▪ This is the reason most important actions/items are performed/executed first
followed by less important ones.
▪ In the similar way there is a need to prioritize tasks or requirements in the software
development as some of the task/requirements are important than others.
one of most
important
exercise in agile
software
development.
What is
Backlog
Prioritization
This Sequence Required to
is followed by organize the
the scrum product backlog
team to choose items to make
product backlog the sequence of
items during its development
grooming or and
sprint planning. deployment.
Benefits
Benefits to Business Benefits to Scrum Team
Fastest Return Of Effective Grooming by saving
Investment time of selection story
Customer satisfaction Effective Sprint Planning by
saving time of selection story
Minimizing Risks Better visibility to pick
stories within current sprint
scope, if there are
bandwidth
Keep focused on Value Better visibility to drop
driven development. stories from current sprint
scope, if bandwidth reduce
All Items in product backlog are treated equally during backlog prioritization, that can include,
Defects or Bug, New Functionality, Enhancements, Spikes.
Risk &
Complexity
Opportunity
Effected No of
Business
Users/frequency
Value
of use
Influencing
factors for
Customer
Satisfaction backlog Cost
prioritizati
on
1. Customer Satisfaction
Primary factor to be considered.
Functionality which has a higher customer satisfaction probability should be given highest priority.
Basic needs should be implemented first followed by performance are and then the delightful
functionality.
2. Business Value:
To prioritize a functionality the most essential thing is to understand the business goals & strategies,
this is the reason prioritization should be done by PO/BA.
To prioritize the PBI it is mostly required to identify the functionality which adds most value to meet
business goal.
3. Complexity
Its better to start working on the requirements/functionalities with higher complexity/difficulty during
the early stages of the project.
4. Risks
Its always advisable to keep the high-risk functionalities at the top of the list unlike keeping
them for the later stage which increases the risk of implementation.
5. Effected number of users / or frequency of use:
This is a product specific influencing factor.
Some requirements/functionalities can be prioritized based on the affected number of users.
Similarly, requirements/functionalities can be prioritized based on the frequency of
use( used more often by users).
6. Cost to develop and implement the functionality:
Keeping the cost in mind return of investment( functionality) should be considered.
Low cost – High return should be given top priority and in the same High cost – low return
can be low priority.
Also, High cost – high return can also be at top of the list, considering other factors of
prioritization.
Prerequisites :
[Link] the factors: Identify the priority stories using the influencing factors a.)
Customer Satisfaction, b.) Business Value, c.) Complexity, d.) Risk, e.) Effected No of users
e.) Cost.
[Link]: Allocate the weightage to each considering factor, in case if PO feels all the
factors are of equal weight for a particular project, its worth giving same to all
[Link] the backlog Ready: An backlog should be made ready & available with the items
including Defects, stories, Spikes etc.
[Link]: Define a scale to provide rate to each story against its consideration factors.
Explanation:
▪ In the above figure 3 factors have been considered - a.) Customer Satisfaction, b.) Business Value, c.) Cost.
▪ Weightage has been provided for the 3 factors Customer Satisfaction-12 , Business Value-10 Cost-7.
▪ Scale of 1-10 has been provided for the stories depending on the considered factors mentioned top row.
▪ Each story has a total value in the 2nd last column. Its represents the cumulative value of all the factor’s
value for that story. Factors value for a story is calculated as weight multiply by its Rate.
▪ The last column represent the priority or rank of the story, maximum value is on high priority with rank 1,
and minimum value is low priority. In this example the top priority story is story 6, and lowest priority story is
story 3 and story 4.
Roles & Responsibilities:
Product Owner Scrum Master
Responsible Facilitate the
for prioritizing the prioritization, by
backlog, and ensure working closely with
the team delivers product owner, and
most valuable does not decide on
functionality first. prioritization
Development Team
Typically observe the process
and may provide inputs on
request.
At least once a
week depend upon
what stages PBI is
Some techniques PBI under Initial
need size or When to do stage (Backlog) or in
estimated value to
prioritize, which
prioritization Groomed or
Defines stage are
need groomed potential
stories candidates
No Need to
Prioritize the PBI
that are committed,
in progress,
completed or
accepted
Prioritization Techniques:
MoSCoW Ranking
(Must Have, Should Have, Using this technique
Could Have, Would like to prioritization can be
have) done based on ranking of
As each category says, team the PBI based on the
prioritize the Must have different influencing
functionality first followed factors
by Should have, Could have
and would like to have.
Affinity Analysis
With this technique stories are
categorized into different baskets
like high low medium etc. and
pick backlog items to groom, plan
or construct.
Techniques:
Ranking:
Ranking items is another way of prioritizing backlog items in stack, A rank value
(1,2,3,4,5…).
With this method we organize our backlog items in stack, one above another.
The Rank 1 considered as high priority than rank 2.
In the backlog the higher ( low number value) rank or high priority appears above
the relatively lower rank (high number value).
We pick the top product backlog item first to groom, plan, construct etc followed
by the lower rank.
2. Kano Model:
With this technique we arrange our backlog items keeping in mind the customer satisfaction factor.
The Kano Analysis chart have different areas of customer satisfaction, and we place our backlog items on those areas, and
prioritize accordingly. The different areas of functionality are as below:
1. Must be Functionality
These are expected by your customers. These are the features that will not WOW them. They must be included in your
product, and are often taken for granted
2. One Dimensional Functionality
These are the functionalities that satisfies the customer if implemented and dissatisfy if not implemented. These
functionalities are often discussed with mutually agreement between development team and business/customer.
3. Attractive Functionality
These make users happy when they’re there, but don’t disappoint them when they’re not. Those functionalities are
often not demanded by the customer, but customers get delighted by having those functionality.
4. Reverse — These make users unhappy when they’re there, happy when they’re not. For example, you might implement
high-security features requiring an extra step to login. However, if customers do not value enhanced security, they will
become dissatisfied with the extra step.
5. Indifferent Functionality
These functionalities are neutral nor good or bad, implementing them or not implementing them does not satisfy or
dissatisfy the customer.
MoSCoW:
MoSCoW is another method of prioritizing work items in Product development.
The acronym derived from the first letter of its 4 prioritizing category (Must Have, Should Have, Could Have, Would like to
have).
As the name of the each category, team prioritize the Must have functionality first followed by Should have, Could have and
would like to have.
It is generally used to get the return of benefit faster, reduce the loss of high importance functionality in case of time or
budget constraint.
Affinity Analysis:
With this technique we categorize our user stories into different baskets like high low medium etc. and pick backlog items to
groom, plan or construct.
This technique is mainly used for basketing Product backlog items to prioritize in groups.