Thinking Hub

Important e-mail, important tasks, important user stories, important goals… It is never ending story. Everything is important, isn’t it? What about when you are dealing with product?

“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team”.

Scrum Guide 2020

It states that ordered list is quite important attribute of the backlog. It is create transparency and understanding about what is next to do.

Let’s say that you open your requirements list or your product backlog. How does it look like? Is most prioritized item on top? Is there any order in the backlog? Product backlog is a living artifact. Regular evaluation and work on requirements are required to keep product backlog ordered. When you know different techniques about prioritization, your life gets easier. Although there are several techniques for requirement prioritization, this article provides an overview about MoSCoW, Cumulative Voting and Kano Classification techniques.

MoSCoW

One of the useful and easy technique for requirement prioritization is MoSCoW. It was developed by Dai Clegg in 1994.¹

Must have: Critical functionalities of the product falls in this group. This type of requirements are non-negotiable.

Should have: These requirements are important and can be part of the product or project plan. But without them, project will not fail.

Could have: Desirable requirements are part of this category. It creates value for customer with low cost. But there is no necessity to have them

Won’t have: Least critical or lowest value requirements. Not part of product strategy for current timeline. Maybe in the future can be part of the product scope.

Cumulative Voting

In case you want to include your stakeholders into game for prioritization, this technique may be right for you. You may encounter the 100 dollar technique, which is another name of Cumulative Voting technique. Each participants have fixed amount of unit to distribute to requirements. When each stakeholder allocates units to requirements, number of units will represents priority of that requirement.

Let’s say you have 100 point and you distribute these based on your priority. When each participants complete this activity, final picture shows most priority item. Drawback of this technique is that it does not scale when you have too many requirements.

Kano Classification

Kano model was developed by Dr. Noriaki Kano to show how customer perceive quality². This technique helps you to categorize your requirements based on market needs and customer satisfaction. There are three categories:

• Dissatisfiers: Basic quality attributes. These can be classified as must-be attributes. They are non-negotiable requirements and must be part of the product. If such functionality is not available, the customer will be dissatisfied. However, their presence does not increase satisfaction.
• Satisfiers: Performance quality attributes. Satisfaction level varies based on achievement level of these attributes.
• Delighters: These type of requirements are attractive ones. Customer does not expect to have them, but it surprise the customer in good way. Absence of these features does not reduce customer’s satisfaction. If you want to attract new customers, you should consider to have them in the product.

When you have kano model analysis on your requirements, you can prioritize them as Must be features first, then performance features and finally delighters.

Maybe you have already ordered backlog or you are about starting new product/project or you are just curious person to like learn new things; now you have overview about MoSCoW, Cumulative Voting and Kano Model. Just select one of the technique and try out. I would be happy to hear your experience, do not forget to leave the comment about it.

References

[1] Agile Business Consortium — DSDM Project Framework — MoSCoW Prioritisation. https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html#:

[2] Kano, N. (1984). Attractive quality and must-be quality. Hinshitsu (Quality, The Journal of Japanese Society for Quality Control), 14, 39–48.