Various Prioritisation Approaches for Software Product development
Prioritisation: As a principle, it means doing ‘first things first;’ as a process, it means evaluating a group of items and ranking them in their order of importance or urgency. In Agile-based frameworks, prioritised product backlog is one of the key artefacts for software development.
“Without prioritisation, everything is important — so nothing is important.”
Why do we need to prioritise :-
- Impossible to build a whole system with full features at once — priorities define a path
- Keeps team focused on building most relevant features for business and users
- Reduction in costs — Develop a feature/theme when it is of utmost priority so that we don’t need to maintain the code which is not the need of the moment
- Helps in facilitating release planning
The Pareto principle states that roughly 80% of the effects come from 20% of the causes. Put differently: 80% of the company’s or project’s benefits come from 20% of the time spent by its staff. In an Agile product development context, the same rule would be something like 80% of the product value comes from 20% of product backlog items. But how can you define what tasks must be included in this “magical 20%”?
Prioritisation Levels:-
- Roadmap Prioritisation — Product Sponsor
- Feature level Prioritisation — Product Owner
- Stories/Backlog Prioritisation — Product Owner/Business + Team
Popular Prioritisation Techniques :-
The horizontal axis tracks how oriented a method is towards getting input from the inside or the outside world. In other words, how much it depends on data and opinions from people external ( e.g. end customers or stakeholders within the company) to the core product development team ( internal ).
The vertical axis shows how quantitative is the method prescribed by each technique. That is, how much of it is based on expert (personal) opinions instead of some kind of metric, classification, voting or ranking.
Let us go through few famous prioritisation techniques.
Value vs. Risk Method :-
One classic way of prioritising is to compare the Value of what is to be done to some other measure of tradeoff like Cost.
However, Mike Cohn also talks about considering Risk as a prioritisation factor in his book, which I’ve found to be an extremely valuable approach for new products and initiatives.
Features are scored in two dimensions: Value and Risk. There are no prescribed ways to estimate value, and for that you may use one of the other techniques presented here. As to Risk, there are multiple kinds, but we’re usually concerned with:
- Schedule risk (e.g. “this might not be done by the time we need it”)
- Cost risk (e.g. “this might cost more to run than what the business case allows”)
- Functionality risk (e.g. “we might not be able to do this”)
There’s a constant struggle between high-risk and high-value. What should be done first? On one hand, if you avoid risky items and go for high-value first, you might develop a large part of the product before hitting a major roadblock. On the other, if you focus on working on high-risk items first, you might end up doing unnecessary work on features that turned out to be less valuable.
The goal is to look for a balanced approach, going for High-risk/High-value first, Low-risk/High-value second ( quick wins ) and finally Low-risk/Low-value. High-risk/Low-value items are best avoided.
MoSCoW Method :-
The MoSCoW method is a prioritisation technique used in multiple management fields to reach a consensus on what’s more important to stakeholders and customers.
Requirements are thus classified as:
- Must have — these are critical and must be included into the product. If even one isn’t included, the release is considered a failure. These can be downgraded if there’s agreement among stakeholders.
- Should have — these requirements are important but not crucial for the release. They’re the first level of “Nice to have”, and generally share the importance of MUST requirements, without being so time-sensitive.
- Could have — these requirements are desirable but not necessary for the release. They’re usually low-cost enhancements to the product. Due to their lower importance, they’re the second level of “Nice to have” features.
- Won’t have — these are considered to be the least-critical or even not aligned with the product strategy. They are to be definitely dropped or to be reconsidered for future releases.
This method offers a quick and simple prioritisation solution. The problem comes with its lack of grading within categories. For instance, how can we know which SHOULD or COULD requirements are more important than others? Because of this limitation, the MoSCoW method is probably better suited for internal projects instead of products with many customers — talking to a handful of stakeholders about prioritisation subtleties will always be easier than a larger scale contact with end customers.
Buy a Feature Method :-
Buy a Feature is a fun innovation game that can be played collaboratively or individually. Here’s how it works:
- A set of features that need to be prioritised are presented to a group of buyers (our customers);
- Each buyer gets a budget of play money to spend on features;
- Each feature is priced according to some measure of cost (complexity, effort, actual cost to develop, etc.) — as long as it’s the same criteria for all features, you can use any one you prefer;
- Each player’s budget should be between a third to half of the total cost for all features;
- It’s possible to play the game in one of two ways:
a) Individually — Players are told to use their budget to buy the features that are most important to them;
b) Collaboratively — Using a pricing scale that makes some features too expensive for individual buyers to purchase. This forces collaboration and negotiation between players to buy features that are valued by multiple players. - As players buy features, collect the money and ask them to explain why they’re buying it;
- The game ends when the money runs out or when players have bought all the features they’re interested in (explain to them beforehand that it’s OK for money to be left over.)
This will yield a valuable set of insights on the most important features for customers, as we can analyze which features got bought the most, the reasons for their purchase and which collaborative bids were made on expensive items.
Buy a Feature is best played in person due to its collaborative character, but there are online solutions if that’s what you need.
The Kano Model Method :-
Noriaki Kano, a Japanese researcher and consultant, published a paper in 19843 with a set of ideas and techniques that help us determine our customers’ (and prospects’) satisfaction with product features. These ideas are commonly called the Kano Model and are based upon the following premises:
- Customers’ Satisfaction with our product’s features depends on the level of Functionality that is provided (how much or how well they’re implemented);
- Features can be classified into four categories;
- You can determine how customers feel about a feature through a questionnaire.
- Satisfaction vs. Functionality
Kano proposes two dimensions to represent how customers feel about our products:|
– one that goes from total satisfaction (also called Delight and Excitement) to total dissatisfaction (or Frustration);
– and another called Investment, Sophistication or Implementation, which represents how much of a given feature the customer gets, how well we’ve implemented it, or how much we’ve invested in its development. - The Four Categories of Features
Features can fall into four categories, depending on how customers react to the provided level of Functionality.
THE FOUR CATEGORIES OF FEATURES IN THE KANO MODEL
- Performance
Some product features behave as what we might intuitively think that Satisfaction works: the more we provide, the more satisfied our customers become. - Must-be
Other product features are simply expected by customers. If the product doesn’t have them, it will be considered to be incomplete or just plain bad. This type of features is usually called Must-be or Basic Expectations. - Attractive
There are unexpected features which, when presented, cause a positive reaction. These are usually called Attractive, Exciters or Delighters. - Indifferent
Naturally, there are also features towards which we feel indifferent. Those which their presence (or absence) doesn’t make a real difference in our reaction towards the product.
3. Determining how customers feel through a questionnaire
In order to uncover our customer’s perceptions towards the product’s attributes, we need to use the Kano questionnaire. It consists of a pair of questions for each feature we want to evaluate:
- One asks our customers how they feel if they have the feature;
- The other asks how they feel if they did not have the feature.
The first and second questions are respectively called the functional and dysfunctional forms. To each “how do you feel if you had / did not have this feature”, the possible answers are:
- I like it
- I expect it
- I am neutral
- I can tolerate it
- I dislike it
For each answer-pair, we use this table to determine the category where the respondents falls, letting us know how he or she feels about the feature.
SCORING TABLE FOR KANO QUESTION PAIRS
From the individual responses and resulting categories you can go into two levels of analysis:
- Discrete: each answer-pair is classified using the table above and feature’s category will be the most frequent across all respondents;
- Continuous: each functional and dysfunctional answer gets a numerical score, which can then be averaged over all respondents and plotted on a 2D graph.
As a general rule of thumb, features should be prioritised such that this order is followed: Must-Be > Performance > Attractive > Indifferent.
Will talk about few other prioritisation techniques in another blog. Pls share your feedback or queries in comments.