Backlog Management

Six Prioritization Techniques

These techniques can be used to prioritize your Engineering Roadmap, support Product Owners/Managers, and even your own tasks.

Peter P. Lupo

--

Photo by Susan Q Yin on Unsplash

A big part of managing our teams’ deliveries is tied to how our roadmaps are prioritized. Usually, a team has one product-driven roadmap and one engineering-driven roadmap to be combined in a delivery plan. While Product Owners and other business stakeholders work to prioritize the product-driven roadmap, Engineering Managers are responsible for doing the same with their team and other stakeholders (including the product roadmap itself, to anticipate engineering needs).

I’ll introduce the most popular prioritization techniques here. A valuable tip is that you can use these to support the product-side prioritization if needed or to prioritize your own tasks and initiatives too. It shall also be helpful to your direct reports if they struggle with prioritization.

It’s also worth considering if your task can be broken into higher and lower priority parts, like an MVP. It may help you adopt any of the techniques below.

The MoSCoW Method

Photo by Michael Parulava on Unsplash

Also known as MoSCoW prioritization or MoSCoW analysis, it stands for Must have, Should have, Could have, Won’t have. As you can imagine, the method categorizes your items under these labels.

  • Must have: This group is comprised of items that are critical and also urgent. If you prioritized features in your product, your [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) would be here.
  • Should have: This includes items that may be as important as the Must have but can be done after the items in the Must have, as they are not urgent. Not all of them may be delivered in the delivery cycle that is being planned.
  • Could have: This group will have items that are “nice to have,” items that will improve the results but are not mandatory. If there are enough resources (time, etc.), some of them might get done.
  • Won’t have: Items in this group are things that stakeholders agree are not critical, maybe not even needed at the time. They are considered out-of-scope for a certain delivery or period. They may be reprioritized later or dropped altogether.

You can read more about it in this Wikipedia article:

Eisenhower Matrix

Former USA President Eisenhower created NASA, incorporated Hawaii and Alaska (Alaska, from the Russians, in the middle of the cold war), Ended the Korean War, and proposed and started building the Interstate Highway System, connecting all states in the USA, among other achievements.

Eisenhower had a very interesting way of prioritizing things that avoided the Mere Urgency Effect (the fact that we tend to prioritize what is urgent regardless of its importance or relevance).

This is one of my favorite approaches to prioritizing work.

The matrix has two axes, importance, and urgency, creating four quadrants:

  • Important and Urgent: Just do it. There will be negative impacts or losses if you don’t. These are the things that actually require your immediate attention and nothing else.
  • Important and Not Urgent: Schedule it for later. This way, you allocate the time needed to handle it and don’t let it become urgent, allowing you to find the appropriate time to do it.
  • Not important and Urgent: If something needs to be done but doesn’t require your attention, just delegate it to someone else. If it’s not done exactly how you would have done it, there shouldn’t be any significant impact.
  • Not important and not urgent: Don’t do it. This time is better applied to the other quadrants.

Impact/Effort Matrix (A.K.A Priority Matrix)

Photo by Theo Crazzolara on Unsplash

The Priority Matrix is similar to the Eisenhower Matrix because it has four quadrants. This time, the axes are the effort (or cost) to do the item (project, task, initiative, etc.) and the impact it causes (or value it brings).

  • Low Effort and High Impact: These are the ones you want to get first. They are low-hanging fruits.
  • High Effort and High Impact: These are the long-term projects and initiatives you want to get started on and potentially include other people in or find ways to reduce the effort.
  • Low Effort and Low Impact: There shouldn’t be any harm in doing items in this quadrant, provided that you have spare time. These are the kind of things you may also want to delegate. Make sure that what’s a low effort for you is also of low effort to whoever will execute it. ;-)
  • High Effort and Low Impact: This will just consume time. If you can, don’t do it at all, and don’t delegate it, either. Simply skip it if there is an option.

Rice

Photo by Maria Ionova on Unsplash

The RICE method is a more sophisticated approach to Effort/Impact. It stands for Reach, Impact, Confidence, and Effort, the four aspects you will need to estimate for each item to be prioritized.

It was originally developed by Intercom (a customer communications platform organization).

Here is what they say about each aspect in their blog post about RICE (replicated here as-is):

  • Reach: how many people will this impact? (Estimate within a defined time period.)
  • Impact: how much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)
  • Confidence: how confident are you in your estimates? (High = 100%, Medium = 80%, Low = 50%.)
  • Effort: how many “person-months” will this take? (Use whole numbers and a minimum of half a month — don’t get into the weeds of estimation.)

Then you will calculate the RICE Score: (Reach * Impact * Confidence)/Effort. The result means “total impact per time worked”; therefore, you will want to maximize it.

In this approach, you should simply start with the highest scores.

In their blog post, they were kind enough to provide a Google Sheets link and an Excel file to be used for free. I encourage you to check out their original post for more detailed information.

ICE

Photo by Sergey Pesterev on Unsplash

If you heard of Sean Ellis, you probably have heard about “Growth Hacking” (or, as he also calls it, “experiment-oriented marketing”). Sean Ellis is the founder of GrowthHackers, and they have a blog on Medium.

His prioritization approach, called ICE (Impact, Confidence, Ease), is a simpler version of RICE presented above, in which Reach is removed from the equation and Effort is referred to as Ease (turning a “negative” measure into a “positive measure”).

In their blog post about ICE, they define each term (replicated as-is):

  • Impact: How impactful do I expect this test to be?
  • Confidence: How sure am I that this test will prove my hypothesis?
  • Ease: How easily can I get launch this test?

By changing Effort into Ease, this measure is no longer inversely correlated to a positive outcome. Therefore, they can all be combined by simply scoring each one from 1 to 10 and calculating the average for each item. As with RICE, you will want to start from the highest ones.

Weighted Shortest Job First

Photo by Brett Jordan on Unsplash

This technique is recommended in the Scaled Agile Framework (SAFe) and can also be seen there.

This is a simple but very powerful concept, published by Donald G. Reinertsen in his book “The Principles of Product Development Flow: Second Generation Lean Product Development.”

The strategy combines the cost of delaying the item (in his example, a project) with its duration. By considering the cost of delaying, the strategy tries to minimize the impact of getting something done too late. It tries to find a global optimization instead of simply executing the shortest project or the most beneficial one (putting at risk many smaller ones that combined could yield better benefits if they weren’t delayed).

In Reinertsen’s words:

The total profit of a high ROI project may be less sensitive to a schedule delay than that of a low ROI. In such a case, the low ROI project should go first. Overall portfolio ROI adjusted for delay cost is more important than individual project ROI.

He also makes an analogy of a hospital emergency prioritizing patients by FIFO, which would be a disaster.

So, the strategy here is to divide the cost of delay by the duration and start with the highest one.

In the SAFe, they recommend calculating the cost of delay by considering business value, time criticality, and risk reduction/opportunity enablement value. Other interesting tips are that you should be able to use the project’s size (for instance, in story points) or its cost (if you have a good estimate) to replace the duration.

I hope these simple strategies will help you prioritize your tasks, initiatives, or projects. They are simple yet powerful.

Let me know in the comments below if you have used any of them and what your experience was. Did you obtain the results you expected?

Cheers!

If you like this story, hit the clapping hands at the end so I know what you want to read about.

I don’t make a dime with the blog. If you want to support the creation of more content, share the blog with your coworkers and follow it to be notified of new stories!

--

--

Peter P. Lupo

Many management blogs focus on soft skills. This blog is about hard skills! Measurement, indicators, approaches, etc., for Software Engineering Management.