I already talked a bit about prioritization in another post and how, in real life, this is a complex problem to solve since each case can require different approaches. Today I want to talk again about prioritization, but this time I will focus on the metrics and process I usually use to gather data that will support me in my decisions.
MoSCoW
MoSCoW is a prioritization process that I like using to organize my backlog, in a higher level of prioritization. All features are categorized in one of the following groups:
Must: It is a critical feature and must be included in the product. One good example of this category is a feature to make your product compliant with some new legislation. Or even a strategic new feature that will make your product to benefit from a market opportunity, or maybe one feature that will allow the company to achieve its vision.
Should: Those are features that are important but not crucial, yet. And I used “yet” because this is the case of this category, it is something you don’t have to do now, but you will. It can also be a new legislation requirement but, since it is not so complex and only will be required next year, it can wait. I could say this category is the first level of “nice to have”, on which the features are actually mandatory but they are not so time-sensitive.
Could: Those are the real “nice to have” level. Features that would, for example, increase customer happiness but would not impact negatively the user experience if it is not done.
Won’t: Those are features that are not critical for the success of the product, or even features that could be nice to have but are not directly aligned with the product strategy or with the company’s vision. Features that are not 100% defined, which has not been proved that can be effective yet or that has some strong impediment (technical impediment, for example) can be in this category. Won’t have features can be later review to another level in the prioritization or even being discarded.
This process helps me a lot on the roadmap prioritization and in release plans. Also, the stakeholders and market inputs are deeply valuable to make the MoSCoW analyzes.
Business Value
Business value is one of the most important perspectives that I analyze while prioritizing my backlog. The Return of Investment (ROI) is one of the most common metrics used in this category, but in some cases may not be the most relevant one. I say that because there are other ways to measure business value.
A simple metric that I used a lot working on the internal applications is related to the hours of manual work that a department of a company will save. A new feature on tax reporting or a new finance report can spare hours of manual work from its respective departments. This will allow them more time to work on more relevant tasks that will bring more value to the company.
The improvement on the quality of data is also relevant to business value. On BI applications I could see it a lot. That can help a company to define the most relevant vision and also to target it better since the data analysis will be improved. This metric can also affect on the manual work time since it can also decrease it.
A new business opportunity may have a low, or even zero, ROI for a couple of years, but could increase the relevance of a business and be good marketing for the company. This can increase a lot the importance of a new feature, and it usually has a high time-sensitive.
Customer Satisfaction
Customer Satisfaction can be a complex metric, since it may be the derivation of many other metrics and, of course, it depends on the business and industry types. But usually, we can get those pieces of information with the marketing department. This gives nice inputs on what the product could improve to reflect in better customer satisfaction. Some stories can have low business value but can bring significant improvement to some marketing indicators.
Complexity
I already reprioritized some stories in a sprint due to its complexity. A complex story can be easily underestimated, which is a high chance to prevent it to be done in one single sprint.
To estimate the complexity of a story, we need to bring the developers on board to help with it. Sometimes, a simple business story can result in a complex technical story. What I like to do in situations like this is to add an investigation story before. This approach is also valuable in stories that are not so clear on the technical implementation. Timebox investigate story can help to achieve better preparation, and even help to break complex stories into small ones.
Another point here is that, a complex feature can stand for a high cost of implementation. In that situation, it is necessary to analyze together the complexity and the ROI of the story or feature to make sure it is still worth to go for it.
Risks
Risk is not only a sensitive metric to be assessed but a mandatory one for every story or feature. The most typical risk metrics that I use are related to the technical risk. This is crucial in a finance application, or any application that deals with customer data or any kind of sensitive data.
There are also other types of risk, like for example the impact a new feature will bring to the usability of the system. An AB test, for example, can help to mitigate it. Complexity can also introduce new risks in the product since it can influence the complexity of the system’s code and make it more complicated to escalate the product in the future.
That’s all folks
Prioritization is a complex topic (sorry, I know I repeat it a lot, but it is true) and there are lots and lots of metrics and processes to support it. The ones I mentioned above are the ones I could remember using lately and that I can see they are valuable and relevant. Sometimes we need to find a way to measure the importance of a new feature, and it can happen that a traditional metric will not give the answer we need. To have a proper indicator to support our decision, we need to be creative and to abstract concepts to find our answer. Anyway, step back, have a better overview of the problem you have in your hands and you will find your best solution.
Experience and business knowledge can be a great support. As more as we know about our product, about the market it targets, about its users and stakeholders, more inputs we have in hands to make better decisions.
I am sorry for the long post and hope it brought some insights for you! 😉