5 Simple Prioritization techniques

Prioritizing requirements is fundamental to Program Management. We need to prioritize to provide direction to the teams and to optimize the value delivered. Following are five simple prioritization techniques you can use. I have used requirements/feature list/ epics interchangeably to indicate that these techniques can be used both for agile / traditional methodologies.

1. Stack ranking

This is a basic technique. As the name suggests, stack rank the feature list / product backlog based on the value delivered. If you have multiple tracks/pillars within the project, stack rank the tracks and within these tracks, stack rank the requirements. Example: Consider you are creating a banking app and you have three tracks. Three different teams are working on these tracks – Login, Dashboard and Payments. As a banking customer, the user would Login first, view their Dashboard and then proceed to Payments. You can stack rank based on the sequence of events. Within each of these tracks you can then stack rank the requirements. If it is an existing system, ensure to tackle some tech debt related features. Ex:

You can stack rank the tracks based on the sequence or priority or any other criteria important for your product/team. If you are running behind on the highest priority requirements then one option to consider is moving team members to work on the highest priority features, provided they have the requiredskill set.

2. MoSCoW

This technique originated by DSDM (Dynamic Software Development Method).  Use this technique to categorize your requirements/epics into four different buckets.

M: Must have – As the name suggests, represents requirements that are mandatory for a given release.
S: Should have – Requirements that are important but not mandatory for a release. Ideally they should be delivered too, but if we have to make a trade-off, these would be left out.
C: Could have – Nice to have requirements which will be included if time permits.
W: Won’t have These requirements will not make it into the current release but will be considered for a future release.

After we classify the requirements into the above four buckets, we need to stack rank the requirements within the four buckets. This technique is very similar to the “Stack Rank” technique described above.

3. Buy a feature

Oftentimes teams feel that all requirements are equally important. Associating a price tag on the features, and giving them fake currency to bid on the requirements will help them prioritize. In this method, create a list of features with a price. Price can be equal to the estimates in days/hours or story points.  Give your stakeholders/customers fake currency worth the price of the total estimates and have them bid on the features. Once everyone has placed their bids, ask the stakeholders why they chose those features and give them opportunity to change their bids. Tally up the totals to get the priority of the features.

4. Relative weighting

Use this technique when you want to prioritize amongst requirements that seem equally important. You should not use this for mandatory requirements because if they are mandatory, they must be built first. Ex: continuing on the banking app example, Registration, Authentication requirements are mandatory. So there is no need to compare them against the other requirements. If you are trying to prioritize between multiple seemingly important requirements like “Link to a credit card” or “Link another banking account” use this technique. This technique requires identifying success factors for your project. Examples of success factors:

  1. Increases new customers
  2. Improves NPS
  3. Complexity
  4. Improves Customer value
  5. Reduces cost etc.

Once you brainstorm the list of success factors, follow these steps:

  1. Select 2 or 3 success factors
  2. List down all the requirements you want to prioritize
  3. On a scale of  1(low) – 10 (high) rate your features  
  4. Calculate each feature’s total value and value percent (Total value for the requirement / Total value for all the requirements . Ex: 10 /37 in the example below)
  5. Estimate the efforts for each of the requirements (story points or estimates in days/hours)
  6. Total the estimates and calculate the Cost Percent (Estimates for the requirement / Total estimates for all requirements. Ex: 40/150 in the example below)
  7. Divide value percent and cost percent to determine the feature priority

Mountain goat software has a tool for calculating the relative percentages. You can use that or create it in excel.

5. Kano Method

Use this technique for new product development. In this method, customer needs are classified into three categories:

  1. Threshold / Mandatory: These are must have product features and do not differentiate the product from other products out in the Market. Ex: Logging into a banking app, Viewing dashboard are basic features.
  2. Performance  / Linear : These are the requirements where more is better and will improve customer satisfaction. Price that the customer is willing to pay is tied to these requirements. Ex: More the square footage of a house, the better.
  3. Exciters: These are the requirements that delight the customers and result in high customer satisfaction. Customers are not necessarily dissatisfied in the absence of these features however they provide competitive advantage over other similar products. Over time exciters become mandatory/standard. Ex: Island in the kitchen. I was very excited when I first saw this back in 2000 and was offered in very few homes. These have become very common in new homes these days.

Include requirements from each of these three categories in your product release.

Summary

Prioritization is fundamental to any software development and each of these techniques provide a way to have meaningful discussions amongst the teams/stakeholders. Having a clear set of priorities, will not only optimize the value we deliver but will go a long way in motivating the team members.

Special thanks: I learnt about several prioritization techniques but forgot most of them and have been using only the “Stack Rank” and “MoSCoW” techniques. I recently attended CSPO training by Mike Cohn where he taught about prioritization techqniques. Just so that I dont forget them again, I wrote this blog with my favorite ones. So thank you Mike!

Sree

Sree is a PMP, PgMP, PMI-ACP certified Technical Program Manager (TPM)

2 thoughts on “5 Simple Prioritization techniques

  • March 25, 2019 at 4:32 AM
    Permalink

    This is a very nice summary of prioritization techniques, Sree. Thanks for including some of my favorites.

    • March 25, 2019 at 5:28 AM
      Permalink

      Thanks a lot Mike. Such an honor that you read my blog and posted a comment!

Comments are closed.