Let’s consider two real-world scenarios. In one, a product manager is asked to work on the top priority items in his project’s product backlog for an upcoming iteration. The product manager replies, “It can’t be done because the business executives have set everything to be of top priority.”
In a second situation, a few stakeholders didn’t want to proceed with a compliance requirement, which had a time limit. Rather, they wanted to pursue another feature expected to bring more value. In this case, the product manager said, “We can make that feature happen in place of the compliance one, except that the CEO has to spend some time in jail, because of non-compliance!”
Now, in the first situation, the product manager has been forced to address all items, because all are high-priority. Do you think anything would be delivered properly at all? In the second one, if the CEO goes to jail, do you think the product manager could in any way keep his or her job?
How could these situations be properly addressed?
If you are thinking that we need prioritization or the right prioritization schemes, you are correct, and this will be our topic of discussion in this article. We will focus on prioritizing items in the Product Backlog, which is a key element of Agile development.
The product backlog (PB) is an ordered list of user requirements, typically owned by the Product Owner or Product Manager, who is the proxy for the customer. Do note that Agile practitioners use the term ordered for product backlog items (PBI) in place of prioritized. Prioritization, after all, is a form of ordering; however, going forward I’ll use these terms interchangeably.
Before we cover various techniques for prioritization, let’s understand the essential qualities of a Product Backlog.
A DEEP Product Backlog
The product backlog is characterized by four qualities, i.e., the PBIs in the PB are detailed appropriately, estimated, emergent in nature, and prioritized. The acronym for it is DEEP.
- Detailed appropriately: It means the high priority items in the product backlog are listed in more detail (or fine-grained) as compared to the low priority items, which are coarse-grained.
- Estimated: The PBIs are estimated. The high priority items can be estimated in story points, ideal days, or any other estimate, whereas the low priority items can be in the form of epics.
- Emergent: The product backlog is not a static artifact. When new items are discovered, they are added to the bottom of the product backlog.
- Prioritized: The items in the product backlog are prioritized, with the highest priority PBIs on top of the product backlog (these items are pulled to be executed in the upcoming iteration). The prioritization of the items is generally done with respect to the value delivered, though there can be other factors as well. We will see more on this shortly.
As you may have noticed, one of the qualities for the PB is that the items are prioritized. However, not all PBIs must be prioritized, rather you should do it for some immediate Sprints or iterations. This also compliments the first quality for the product backlog, (i.e., detailed appropriately).
In fact, the backlog follows the concept of rolling wave planning, (i.e., we plan for few immediate iterations in detail, whereas the future iterations will at a higher level). This has been illustrated in the below figure.
Earlier, I noted prioritization occurs generally with respect to the value delivered, but there can be other factors at play, as well. Let’s take a look at some of the other factors for prioritization now.
Factors in Prioritization
Below is a list of factors which help to prioritize:
- (Business) Value of having the features
- Cost of developing the features
- Compliance, i.e., set of rules considered safe to be followed such as regulations
- Knowledge gain, which tells to what extent the team will gain them while working on features
- Amount of risk removed by having the features
- Resources available because a particular backlog item may require specialized resources (human or physical) or resource with domain knowledge
- Dependencies among the features or PBIs
These prioritization factors are depicted in the below figure.
With these basics in mind, let’s consider some of the techniques used in prioritization.
Various Techniques for Prioritization
Simple Scheme
Here we label feature items as “Priority 1,” “Priority 2,” “Priority 3,” and so on, or “High,” “Medium,” and “Low” items. One of the drawbacks in this scheme is that business executives want everything to be P1 or high priority types.
Monopoly Money
The sponsors of a project are given an equal amount of money for the project budget, and then asked to distribute it amongst system features. This is effective only when limited to prioritizing business features.
100 Point Method
This is a scenario where each stakeholder is given 100 points that he or she can use to vote for the most important requirements. How points are distributed is up to them – 30 for one item, 20 for another, or even all 100 points for a single item. This method was first developed by Dean Leffingwell et al.
Kano Analysis
Kano Analysis (or the Kano model) informs regarding product features which are perceived to be most important to customers. This method was created by Dr. Noriaki Kano and focuses on differentiating product features, as opposed to focusing initially on customer needs. This analysis involves two dimensions:
- On X – axis: The product feature presence is listed.
- On Y – axis: Customer satisfaction is listed.
The features are divided into three levels, which we will understand by considering an example of a phone.
Must-have or Mandatory features:
These are must-have features and mandatory. For example, the basic functions of a mobile phone include switching on/off, making calls, receiving calls, sending/receiving text messages, etc. These are threshold functions, which are basic and necessary to sell the product. Without these, the product is useless. However, beyond a point, on these functions, customer satisfaction does not go up – rather, as shown above, it goes down.
Performance or Linear features:
Here the motto is “the more the better.” The higher the number of performance functions the higher customer satisfaction. For example, if the phone is slimmer, and it boots up quickly, then we have more satisfied customers. The price of the product is related to the linear features, but these are not differentiators to selling the product. For that, we need exciters and delighters.
Exciters and Delighters:
These are related to hidden customer needs, or things that the customer is not even aware of. These provide a unique selling point (USP) for the product; however, absence of these doesn’t necessarily mean that the customer won’t be satisfied. For example, having a face recognition feature in a phone that allows it to unlock. Nevertheless, the presence of such features can lead to premium pricing of the product.
There can also be other levels such as indifferent, which tells us that the feature presence is irrelevant to the customers’ satisfaction, and reverse (i.e., the presence of such a feature will reduce customer satisfaction).
MoSCoW
MoSCoW is another technique for prioritization. The letters stand for:
- M – Must Have
- S – Should Have
- C – Could Have
- W – Won’t Have this time (but would like to have!)
The “Os” are added for easy memorization. The idea in the MoSCoW technique is that instead of prioritizing the requirements as high, medium, or low, priorities are specific.
- Must Have: Minimum Usable Subset (MUS) of features which the project must deliver. The best way to find a must have feature is to ask the question, “What happens if this feature is not available?” If the answer is “cancel the project,” then we have a “must have” feature on our plate.
- Should Have: These are important, but not vital requirements. If you leave them out, it will be painful, but the solution is still viable. If you skip these, you may need some kind of workaround for it.
- Could Have: These are wanted or desirable features, but less important. A “Should Have” may be differentiated from a “Could Have” by reviewing the degree of pain caused by the requirement not being met, in terms of business value or number of people affected.
- Won’t Have this time: These are features which your team has agreed on having in the long run, but will not deliver in this release or iteration.
Cost of Delay Divided by Duration (CD3)
The CD3 method was developed Donald Reinertsen. The name CD3 comes from 3Ds in “Cost of Delay Divided by Duration.” Cost of delay informs what the penalty of cost of delaying these features. This is expressed in a Money/Time format (i.e., $400/week or $150/day). Next, it is divided by the duration or time that will take to build the feature. The feature with the highest score is tackled first or will have the highest priority.
One frequent question I receive is how to model these prioritization schemes with the help of software tools. Let’s work through an example using MS Project software.
Prioritization of Backlog with MS Project Agile
MS Project 2019 supports both Scrum and Kanban. We will use Scrum framework to understand how the backlog items are prioritized, and we will follow the following steps.
Step – 1: Define a Prioritization Scheme
Let’s take a simple scheme, which, as the name tells us, is not only simple, but also widely used. We need to create a custom field. In our case, I’ve created a custom text field “PBI Priority”, which is shown below:
Next, in the look-up table, highlighted in the above figure, you have the option of defining the priority level – high, medium, low, or undefined. The “undefined” level will correlate to the PBI when it’s newly entered into the backlog.
As shown above, we have four levels in the list with the “Undefined” one set as the default.
Step – 2: Enter the Product Backlog Items
You can enter the backlog items into the “No Sprints” column, which is for the product backlog in the Sprint Planning Board view. The items should be estimated, and you can use story points, ideal days, or any other format as needed. This is depicted below.
We have items listed with the default PBI priority “undefined” shown for each item.
Step – 3: Assign Priorities to the PBIs
Next, we will assign the priorities, which, is again, quite simple and straightforward. To do so, I’m using the Sprint Planning Sheet view and choosing the priority for each PBI in the “PBI Priority” field.
Step – 4: Reorder the Product Backlog
The final step is to reorder the product backlog items. This is done by simply dragging and dropping the cards or the PBIs in the backlog, under the Sprint Planning Board view. As you reorder, the high priority items are moved to the top of the backlog, whereas the low priority items will appear towards the bottom. This is depicted below.
If you are using another prioritization scheme associated with a formula, you can define the formula and use the look-up table to set the priorities for the PBIs.
Prioritization of Backlog with MS Project for the Web
Microsoft recently released a new version of Project, Microsoft Project for the Web. With this app or service, you can also create a backlog of items and order the items by dragging and dropping the cards in the Board view.
As shown above, we have a product backlog where the PBIs are listed and ordered. These items will then be subsequently pulled into various Sprints. One great advantage of MS Project for the Web is that you can drag and drop and in turn, change the dependencies. This can be done in the Timeline view, which is shown in the figure below:
I hope you now better understand the various product prioritization techniques and how to apply them with the help of a software tool. Though product prioritization is the job of a product owner or product manager with inputs from team members, it is equally useful to know if you are working as a project manager, scrum master, Kanban flow master, or in any other similar kind of role.
References
[1] I Want To Be A PMI-ACP: The Plain and Simple Way, by Satya Narayan Dash
[2] Microsoft Project Live Lessons with Money Back Guarantee, by Satya Narayan Dash.
[3] Scrum Product Ownership: Balancing Value from the Inside Out, by Robert Galen
[4] Agile Product Management with Scrum: Creating Products that Customers Love, by Roman Pichler
[5] Documentation for Microsoft Project for the Web, by Microsoft Corporation.
