According to our clients the following activities are the most challenging responsibilities for Product Owners. That's why we decided to post this article about prioritization.
In this article we will explain some of the techniques you can use for prioritization. Please keep in mind that you can flex and change any of these techniques according to your organisation’s dynamics. You may have to try and fail and improve your technique.
Effort – Value matrix
In this method, you need to use a big board and manage the collaboration of delivery teams and stakeholders at the same time. On the board, you will draw two axis graph; value impact on the vertical axis and complexity on the horizontal axis as below.
Then, you will start using post-it notes to place features in this graph. I suggest first asking the stakeholders together with the product owner to order the post-its vertically to define the value. Then ask the delivery team to order them horizontally to define the complexity. Especially for the value, there might be disputes. If the Product Owner can’t sort out these disputes, then you can use value mapping techniques which we will not cover in this article but you can easily find different examples on value mapping techniques online. After ordering the items vertically and horizontally, you will end up with a board like below;
After this step, the best practice is to divide it into 4, and prioritize starting from 1 to 4.
Depending on the priorities, sometimes it makes sense to draw a threshold of minimum value limit. This will make you focus more on big bets and less on small incremental changes. However, you should be very careful about this limit because some of these small effort changes can bring quick wins for your product. If you apply such a threshold, your board will look like below.
MoSCoW method
The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritization or MoSCoW analysis. 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 Would have). All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened. Would have requirements even not considered in the plan. Best practice is usually to remove items in that groups after a certain deadline. Otherwise, this category becomes a big list of things that you will never do.
The plain English meaning of the prioritization categories has value in getting customers to better understand the impact of setting a priority, compared to alternatives like High, Medium and Low.
The categories are typically understood as;
Must have
Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must have, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered an acronym for the Minimum Usable Subset.
Should have
Requirements labelled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.
Could have
Requirements labelled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
Would have (or wish to have)
Requirements labelled as would have, have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Would have requirements are not planned into the schedule for the next delivery timebox. Would have requirements are either dropped or reconsidered for inclusion in a later timebox.
Kano Model of Prioritization
Professor Noriaki Kano propagated Kano Model of Prioritization. This prioritization technique involves three levels that include considering customer satisfaction from disappointment to not happy to immediate happiness to get delighted. Two important factors that create an impact on the satisfaction level during this prioritization are the existence of features and the degree of implementation. The level of satisfaction is achieved along with full implementation. Some features lead to a basic level of satisfaction while others create more – the higher the implementation, the greater the level of satisfaction.
These categories have been translated into English using various names (delighters/exciters, satisfiers, dissatisfiers, etc.), but all refer to the original articles written by Kano.
Must-be Quality
Simply stated, these are the requirements that the customers expect and are taken for granted. When done well, customers are just neutral, but when done poorly, customers are very dissatisfied. Kano originally called these “Must-be’s” because they are the requirements that must be included and are the price of entry into a market.
Examples: In a hotel, providing a clean room is a basic necessity. In a call center, greeting customers is a basic necessity.
One-dimensional Quality
These attributes result in satisfaction when fulfilled and dissatisfaction when not fulfilled. These are attributes that are spoken and the ones in which companies compete. An example of this would be a milk package that is said to have ten percent more milk for the same price will result in customer satisfaction, but if it only contains six percent then the customer will feel misled and it will lead to dissatisfaction.
Examples: Time taken to resolve a customer's issue in a call center. Waiting service at a hotel.
Attractive Quality
These attributes provide satisfaction when achieved fully, but do not cause dissatisfaction when not fulfilled. These are attributes that are not normally expected, for example, a thermometer on a package of milk showing the temperature of the milk. Since these types of attributes of quality unexpectedly delight customers, they are often unspoken.
Examples: In a callcenter, providing special offers and compensations to customers or the proactive escalation and instant resolution of their issue is an attractive feature. In a hotel, providing free food is an attractive feature.
Indifferent Quality
These attributes refer to aspects that are neither good nor bad, and they do not result in either customer satisfaction or customer dissatisfaction. For example, thickness of the wax coating on a milk carton. This might be key to the design and manufacturing of the carton, but consumers are not even aware of the distinction. It is interesting to identify these attributes in the product in order to suppress them and therefore diminish production costs.
Examples: In a callcenter, highly polite speaking and very prompt responses might not be necessary to satisfy customers and might not be appreciated by them. The same applies to hotels.
Reverse Quality
These attributes refer to a high degree of achievement resulting in dissatisfaction and to the fact that not all customers are alike. For example, some customers prefer high-tech products, while others prefer the basic model of a product and will be dissatisfied if a product has too many extra features.
Examples: In a callcenter, using a lot of jargon, using excessive pleasantries, or using excessive scripts while talking to customers might be off-putting for them. In a hotel, producing elaborate photographs of the facilities that set high expectations which are then not satisfied upon visiting can dissatisfy the customers.
Relative Weighting Prioritization Technique
The relative weighting scheme is a simple model where prioritization is done based upon all the factors mentioned above. The major factors considered in relative weighing prioritization technique are:
1. The value of a feature and the negative impact that might be caused by the absence of the feature
2. Based on the expert judgment made by the product owner and supported by the agile team in ranking the score of features in the following way (a scoreboard from 1 to 9 is usually used)
Benefit from having the feature
Penalty for not having the feature
Cost of producing the feature
The risk incurred in producing the feature
3. The priority and rank are then determined by dividing the value score as below:
(Benefit score + Penalty score) / (Cost score + Risk score)
Cost of Delay and WSJF
Scaled Agile Framework suggests using Cost of Delay (CoD) measurement as a technique to prioritize the backlog. SAFe describes a comprehensive model, called weighted shortest job first (WSJF), for prioritizing jobs based on the economics of product development flow. Calculate WSJF by dividing the CoD by the duration. Jobs that can deliver the most value (or CoD) and are of the shortest length are selected first for implementation. When applied in SAFe, the model supports some additional principles of product development flow, including:
Taking an economic view
Ignoring sunk costs
Making financial choices continuously
Using decision rules to decentralize decision-making and control
If you only quantify one thing, quantify the Cost of Delay
In SAFe, jobs are the epics and the features and capabilities we develop, so we need to establish both the Cost of Delay and the duration. Three primary elements contribute to the Cost of Delay:
User-business value – Do our users prefer this over that? What is the revenue impact on our business? Is there a potential penalty or other adverse consequences if we delay?
Time criticality – How does the user/business value decay over time? Is there a fixed deadline? Will they wait for us or move to another solution? Are there Milestones on the critical path impacted by this?
Risk reduction-opportunity enablement value – What else does this do for our business? Does it reduce the risk of this or a future delivery? Is there value in the information we will receive? Will this feature open up new business opportunities?
Moreover, since we are in a continuous flow and should have a large enough backlog to choose from, we needn’t worry about the absolute numbers. We can just compare backlog items relative to each other using the modified Fibonacci numbers we use in ‘estimating poker.’ Then the relative CoD is calculated as follows:
You can read more about this technique and also learn more about SAFe from https://www.scaledagileframework.com (I would highly recommend you to do so because there are very useful modules in this framework).
Reference Resources
4. Prioritization Techniques for Agile Teams by Tarang Baxi