Our Product Backlog list seems endless as the contribution comes from so many different sources — internal team, stakeholders, customer, and anyone associated with product.
We cannot build everything “right away” and we want to utilize the team’s effort and resource in the most effective way.
That’s when we require prioritizing of our backlog.
Prioritization frameworks those are commonly used by product team –
- Value vs. Effort
- ICE Scoring
- RICE Scoring
- Kano Model
- MoSCoW Method
Value vs Effort:
A 2×2 prioritization matrix is simply a visual representation of the Value vs Effort framework. Along the vertical axis, we have value (or benefit, or impact) and along the horizontal axis, we have effort (or cost, or risk, or complexity). Then, each feature gets plotted on the chart.
Here’s what each quadrant can tell us:
- High value, low effort (“Quick wins”): These are the low-hanging fruit. These are the ideas that don’t require tons of development effort, time, or money and the market also needs those.
- Low value, low effort (“Maybe later”): These are the “maybes”, the “will get to it later when the scope opens up a bit more”.
- High value, high effort (“Big new features”): These are the ideas that need a strategic approach. Team will definitely work on implementing these ideas at some point in the future.
- Low value, high effort (“Time sinks”): These are the ideas that can afford to pass up. They’re not worth doing at the time of the assessment, and they’re not likely to become a priority for a while.
ICE is an acronym for Impact, Confidence, and Ease. Each word is given a score from 1 – 10, with all three numbers being added for final ICE score. Each initiative is prioritized based on the highest numbers and the prioritization follows in consecutive order.
Impact – Determine how impactful this initiative or feature will be. Will this new feature positively impact the user, market or business? if so, by what degree?
- 1 – Very low impact
- 2 – 5 – Minimal impact
- 6 – 8 – Measurable impact
- 8 – 10 – Significant impact
Confidence – How confident we are that this feature or initiative will prove our hypothesis? How risky is it to invest time and resources into this initiative?
- 1 – Very low confidence
- 2 – 5 – Minimal confidence
- 6 – 8 – Measurable confidence
- 8 – 10 – Significant confidence
Ease – How easy will it be to develop, test and launch this feature?
- 1 – 2 – Long time frame (ex: 3 – 6 months)
- 3 – 5 – Significant time frame (ex: 2 months)
- 6 – 7 – Minimal time frame (ex: 1 month)
- 8 – 10 – Short time frame (ex: 2 weeks)
How does the ICE Scoring Model Work?
Once we’ve created a number from 1 – 10 for each of the categories, we can multiply to get the total. For example:
Feature 1: Impact (9) x Confidence (8) x Ease (5) = 360
Feature 2: Impact (7) x Confidence (6) x Ease (5) = 210
As we can see from the example above, Feature 1 has a higher impact score but will require more from the team to develop it. Based on the overall score, Feature 2 moves to the top of the priority list.
RICE—which stands for Reach, Impact, Confidence and Effort—is a simple prioritization framework for quantifying the potential value of features, or initiatives. A RICE score helps product managers quantify the estimated value of a feature or idea so they’re easier to sort when it’s time to decide the order they should be worked on.
Reach — How many users would be affected by this feature?
Impact — How much would be the impact to any goal (e.g. impact on revenue, conversion, traffic, referrals, etc)?
(Massive — 3, High — 2, Medium — 1, Low — 0.5, Minimal — 0.25)
Effort — How many development sprint is required to complete the feature to launch.
Confidence — How confident are you in your estimates?
(High — 100%, Medium — 80%, Low — 50%)
Combine the factors into a score (RICE) Score –
RICE Score = Reach x Impact x Confidence / Effort
Sample RICE Scoring:
Noriaki Kano, a Japanese researcher, published a paper in 1984 with a set of ideas and techniques that help us determine our customers satisfaction with product features. These ideas are commonly called the Kano Model and are based upon the Customers satisfaction and product functionalities. The level of functionality of product features determines the levels of user satisfaction.
- Must have — these are critical stories and must be implemented with top priority. The absence of any one of them could hamper user experience greatly. These are part of “Basic Expectation” as per Kano Model. For example, solving a critical bug or adding a feature without which a user’s workflow is incomplete.
- Should have — these requirements are important but not crucial for the release and can be implemented in one of the following sprints. They’re the first level of “Performance”, or “Basic Expectations” that are not time-sensitive.
- Could have — these requirements are desirable but not necessary for the release. They’re the “DELIGHTERS”.
- Won’t have — these are features that are not aligned with the product goals. They are the “INDIFFERENT” as per Kano Model.
The MoSCoW is a technique used in managing requirements. It helps to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.