Prioritization Techniques

As we product owners know that product backlog is the single source of truth for any development work. Product backlog is a living document and it keeps on getting refined over the life cycle of the product. At any point in time product backlog contains new features, bugs, test requirements etc. In between the sprints product owner works with the development team on backlog refinement. Backlog refinement (or grooming) is also important because development team has a limited capacity and they cannot work on all the product features at once. Therefore, Agile teams must use prioritization to decide which features to focus on and which lowest rank-order features could be pushed out of scope before the next Sprint.

One may ask what is the basis of picking up a feature request story over the other?

I have seen scenarios when Product Owner, team make a judgement call (based of their product/application experience). Which might or might not be a correct decision in the longer term.

There are number of techniques available to help product owners/managers when it comes to effective prioritization. But, I will just focus on three.

  • Kano’s model
  • MOSCOW Technique
  • Cost of Delay

Kano’s Model – Dr. Noriaki Kano, a professor of quality management at the Tokyo University of Science, created the Kano Model in 1984. The Kano Model can be a helpful framework for product teams with limited time and resources who want to make sure they are prioritizing the appropriate mix of features to work on next. Dr. Kano isolated and identified three levels of customer expectations.

  1. Basic level includes all essential features that customers assume are included with the product. A product without these features would come as an unpleasant surprise to a customer. For example. A car without a seat belt.
  2. Performance level features are ones which a customer asks for and are not always included in the product. The more performance features you include the better it will be from the customer satisfaction perspective. For example, a car without front air bags.
  3. Exciters include features that your customer haven’t even thought about, but are thrilled once they have them. Taking the car analogy forward, seamless smartphone integration would be one such feature.

MOSCOW Technique – MoSCow Prioritization Technique plays a key role in Agile Project Management. In an Agile project it is vital to understand the importance of different things. This is because time is a fixed resource, so prioritization is applied to requirements, tasks, products, user cases, etc. 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 Won’t have)

  1. Must Have: Another way to refer to this is as the minimum usable subset (MUS) or what the project must deliver. In other words, the project must deliver these on the target date for the project to remain on track. No delay is acceptable.
  2. Should Have: This type of requirement is almost as important as a MUS, but it’s not vital to the success of the project. In other words, the project doesn’t depend on this requirement. You might not want to leave it out, as it could have great impact on the project, but in the end it can be done without causing any irreparable harm. 
  3. Could Have: The difference between a should-have requirement and a could-have requirement is simply by figuring out the degree of pain that would be caused by not meeting it. That is, how will it impact the business value of the project, how many people would be affected, etc. Therefore, a could-have requirement is something you’d like but is less important than a should-have requirement.
  4. Won’t Have: Here is where you can collect those requirements that are not feasible for a specific release. Maybe next time, but the project remains strong without them. Once initiatives are placed in the not have time category, teams know that they’re not a priority for this go-around and can place them on the back-burner and out of their mind. 

Cost of Delay Cost of delay (CoD) is a key metric that represents the economic impact of a delay in project delivery. It is a way of communicating the impact of time on the outcomes we hope to achieve.

Examples of possible CoD:

  1. Product development – the amount of money you will lose if the launch of youzzzr new product will be two months later.
  2. Software development – the amount of money you will lose if the release of an essential feature causes a big client to move to a competitor.
  3. Solution implementation – the amount of money you will lose if you fail to replace the existing ERP system by the end of this year.
  4. IT operations – the fines you have to pay if your systems do not comply with new regulations on time (GDPR, FATCA, etc.).

So, just in case if you have 3 competing feature/plugin requests and you can pick only one. Then, you can use Cost of delay technique of prioritization. There is a term called Weighted Shorted Job First (WSJF): it is used to sequence EPICS to produce maximum economic benefits. It is calculated when Cost of Delay is divided by the duration (time taken to develop and deploy that feature). We will pick the feature with the highest WSJF value.

Say, for an example Cost of Delay for the features A, B and C are 200, 300 and 100 respectively and time taken to develop A, B and C are 1 month, 2 month and 3 months respectively. WSJF values for A. B and C would be 200, 150 and 33.33 respectively (COD/Duration). According to the rule, we will pick the features in following order – A, B and C.

Summary – If backlog items are turning into a large and UN-managed queue, it’s time to prioritize. As pointed out, there are numerous ways to so. No, prioritization is not a perfect science, but the important thing is to get started. With some experience, you’ll discover which method or combination of methods work best for your product and team. Remember, dedicate your attention where it’s most needed and keep everyone on the same page.