We know that product backlog is the single source of truth for any development work. A product backlog is a living document and it keeps on getting refined over the life cycle of the product. At any point in time product backlog contains new features, bugs, test requirements etc. In between the sprints, the product owner works with the development team on backlog refinement. Backlog refinement (or grooming) is important because the development team has a limited capacity and they cannot work on all the product features at once. Therefore, Agile teams must use prioritization techniques to decide which features to focus on for the next release cycle.
One may ask what is the basis of picking up one feature over the other?
I have seen scenarios when the team make a judgement call (based on their product/application experience). Which might or might not be a correct decision in the longer term.
There are a number of prioritization techniques available to help product owners/managers when it comes to effective prioritization. But, I will just focus on the following.
- Kano’s model
- MOSCOW Technique
- WSJF
- RICE
Kano’s Model
Dr Noriaki Kano, a professor of quality management at the Tokyo University of Science, created the Kano Model in 1984. The Kano Model can be a helpful framework for product teams with limited time and resources who want to make sure they are prioritizing the appropriate mix of features to work on next. Dr Kano isolated and identified three levels of customer expectations.
- The basic level includes all essential features that customers assume are included with the product. A product without these features would come as an unpleasant surprise to a customer. For example. A car without a seat belt, a hotel room without hot water.
- Performance level features are ones that a customer asks for and are not always included in the product. The more performance features you include the better it will be from the customer satisfaction perspective. For example, a car with front airbags, and a hotel with free WIFI connection.
- Exciters include features that your customer haven’t even thought about, but are thrilled about once they have them. Taking the car analogy forward, seamless smartphone integration would be one such feature.
The way one goes about it is by conducting a customer survey and asking the following two questions:
- Functional: “How do users feel if they have the feature?”
- Dysfunctional: “How do users feel if they didn’t have the feature?”
Responses are then plotted against functional vs dysfunctional metrics. Hence while coming up with product MVP we need to consider all basic, all possible performance and a few exciting features.
for more details, please visit – https://foldingburritos.com/blog/kano-model
MOSCOW Technique
MoSCoW Prioritization Technique plays a key role in Agile Project Management. In an Agile project, it is vital to understand the importance of different things. This is because time is a fixed resource, so prioritization is applied to requirements, tasks, feature requests, bugs, etc. The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won’t have).
- Must-Have: Another way to refer to this is as the minimum usable subset (MUS) or what the project must deliver. In other words, you fail to deliver the Business Case without must-have items.
- Should Have: This type of requirement is almost as important as a MUS, but it’s not vital to the success of the project. In other words, the project doesn’t depend on this requirement. You might not want to leave it out, as it could have a great impact on the project, but in the end, it can be done without causing any irreparable harm.
- Could Have: The difference between a should-have requirement and a could-have requirement is simply figuring out the degree of pain that would be caused by not meeting it. That is, how will it impact the business value of the project, how many people would be affected, etc. Therefore, a could-have requirement is something you’d like but is less important than a should-have requirement.
- Won’t Have: Here is where you can collect those requirements that are not feasible for a specific release. Maybe next time, but the project remains strong without them. Once initiatives are placed in the not have time category, teams know that they’re not a priority for this go-around and can place them on the back-burner and out of their mind.
For more details, please visit – https://medium.com/managing-digital-products/the-moscow-method-how-to-prioritize-feature-backlog-and-get-valued-functionality-faster-f186d5af1a90
WSJF
WSJF (Weighted Shortest Job First) questions the Cost of Delay: how much will it cost the company to delay building the feature? Cost of Delay (CoD) is a key metric that represents the economic impact of a delay in project delivery. It is a way of communicating the impact of time on the outcomes we hope to achieve.
Examples of possible CoD:
- Product development – the amount of money you will lose if the launch of your new product will be two months later.
- Software development – the amount of money you will lose if the release of an essential feature causes a big client to move to a competitor.
- Solution implementation – the amount of money you will lose if you fail to replace the existing ERP system by the end of this year.
- IT operations – the fines you have to pay if your systems do not comply with new regulations on time (GDPR, FATCA, etc.).
So, just in case you have 3 competing feature requests and you can pick only one. Then, you can use the WSJF technique of prioritization. It is used to sequence EPICS to produce maximum economic benefits. It is calculated when the Cost of Delay is divided by the duration (time taken to develop and deploy that feature). We will pick the feature with the highest WSJF value.
Say, for example, the Cost of Delay for the features A, B and C are 200, 300 and 100 respectively and the time taken to develop A, B and C is 1 month, 2 months and 3 months respectively. WSJF values for A. B and C would be 200, 150 and 33.33 respectively (formula – COD/Duration). According to the rule, we will pick the features in the following order – A, B and C.
*CoD is usually the sum of User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement Value
RICE
The RICE scoring model is a framework designed to help product managers determine which products, features, and other initiatives to prioritize on their roadmaps by scoring these items according to four factors. These factors, which form the acronym RICE, are Reach, Impact, Confidence and Effort.
To use the RICE scoring model, you evaluate each of your competing ideas (new products, product extensions, features, etc.) by scoring them according to the following formula:
Reach usually reflects the number of people who will use the feature or be able to use it in a particular time period.
Impact depicts how will this impact individual users? How much the idea will positively affect the key metric (like reducing the churn rate, increase the user signups or monetization) you’re trying to improve. (Scale of 1 to 10, 1 being low impact and 10 being the highest impact).
Confidence. Based on the knowledge obtained, you estimate how sure you are about the given feature benefit. it is measured in terms of %. 100% for high and 50% for low.
The effort shows the time taken by the product teams. This can be calculated in person-months.
The bigger the value of the RICE scores higher the priority.
Conclusion
If backlog items are turning into a large and UN-managed queue, it’s time to prioritize. As pointed out, there are numerous ways to do so. Prioritization is not a perfect science, but the important thing is to get started. With some experience, you’ll discover which method or combination of methods work best for your product and team. Remember, dedicate your attention where it’s most needed and keep everyone on the same page.
Product Management Blog 