At any given time, Product Backlog contains features / user stories at myriad sizes with varying levels of details. As the backlog evolves over a period, teams usually would keep the important and clear stories at the top. This is achieved by regular prioritization.
What is Product Prioritization?
Product Prioritization is the cadence of keeping relatively significant (that is contextual) features at the top for the teams to work on.
Why do we need Prioritization?
The Pareto principle (also known as the 80/20 rule, the law of the vital few, or the principle of factor sparsity)[1][2] states that, for many events, roughly 80% of the effects come from 20% of the causes.[3] Management consultantJoseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto. Essentially, Pareto showed that approximately 80% of the land in Italy was owned by 20% of the population. (https://en.wikipedia.org/wiki/Pareto_principle)
Later Pareto rule was found effective in many situations like:
- 80% company’s business comes from 20% of its customers
- 80% of a country’s wealth owned by 20% of its people
- 20% of bugs affect 80% of the customers
- 20% of the features take 80% of the time
In Product Development, most of the teams have observed that 20% of the features provide 80% of the value. Hence, regular prioritization of the stories based on agreed upon parameters, enables the teams to delivery maximum value.
How do we Prioritize?
First of all, let us look at the factors that influence the priority.
- Business Value
- Cost
- New knowledge that will reduce uncertainty
- Risk
- Releasability
- Dependencies
Agile teams have used various techniques to prioritize their backlog. Let us look at a few:
Technique #1: MoSCOW- Assigning the following to stories and sort the backlog
- Must Have – this now
- Should Have – this if possible
- Could Have – this if other priority items are not affected
- Won’t Have – this now, may be later
Technique #2: Kano model
The features are assigned one of the following based on the customer expectation:
- Attractive
- One-Dimensional
- Must-Be
- Indifferent
- Reverse
Technique #3: Business Value Based
Here, each story carries a perceived business value assigned by Product Owner or Business Team. Based on its values, the backlog is sorted.
Technique #4: Walking Skeleton
In this model, a bare minimum set of features are identified to achieve or validate a specific purpose. Set of stories fall in this category are grouped together to form a Walking Skeleton version. Usually this set, covers end to end flow to be able to complete in a shortest possible time so that the team can feedback.
Technique #5: Balancing Business Value and Technical Risk
Conclusion:
Product Managers break down the big picture into actionable steps by various slicing and dicing techniques. Prioritization ensures teams work on the right thing always, By getting the priorities right, they may get the next million $ product.
Previous Articles in Product Visioning series:
Product Visioning : https://pm-powerconsulting.com/blog/product-visioning-5-steps-scoping-software-projects/
Product Visioning: 1. Elevator Pitch: https://pm-powerconsulting.com/blog/product-visioning-elevator-pitch/
Product Visioning: 2.1 User Persona: https://pm-powerconsulting.com/blog/product-visioning-2-1-user-persona/
Product Visioning: 2.2 User Goals, Pains and Gains: https://pm-powerconsulting.com/blog/product-visioning-identifying-right-target-persona/
Product Visioning: 2.3 Building Hypotheses using Persona and their Goals, Pains and Gains: https://pm-powerconsulting.com/blog/product-visioning-2-3-building-hypotheses/
Product Visioning: 3.1 User Journey Map: https://pm-powerconsulting.com/blog/product-visioning-user-journey-map/
Product Visioning: 3.2 Features-Advantages-Benefits: https://pm-powerconsulting.com/blog/product-visioning-fab-feature-advantage-benefit/
Courtesy: https://www.mountaingoatsoftware.com/blog/why-your-product-backlog-should-look-like-an-iceberg
