Feature Prioritization: Apply the Highest Counter-Value (HCF) First!

Hans-Jörg Roser
Product Coalition
Published in
6 min readSep 18, 2022

--

You can’t expect to be able to prioritize topics only by intuition and experience. Whether we talk about stories, epics, themes or complete initiatives, there is a big value in finding out what is the value you get from the investment. To ensure successful prioritization — there are different variables that have to be considered.

Weighted Shortest Job First (WSJF) and its challenges

Weighted Shortest Job First (WSJF) has established itself as a well-known method for prioritization of product backlog work, because it targets the interdependence between Cost of Delay and Job Size. But with its wording and the used variables it sometimes falls short. Management aspects are missing that are relevant for internal projects as well as software development and other product developments.

The reasons why WSJF falls short are that it’s missing variables influencing the priority. On the other hand, working with Job Sizes is not the way to go in an agile environment.

The conclusion of agile work is that you shouldn’t estimate too early in detail, because there is too much uncertainty within the backlog topics (epics/stories, etc.).

Instead we have to find iterative ways through the jungle. While it is totally fine to estimate job size for a concrete user story, it doesn’t serve well for more abstract topics, like typical epics. The simple formula of WSJF and the idea of the connection between Cost of Delay and Job size is right.

Why Highest Counter-Value (HCF) works

Highest Counter-Value (HCF) and all other calculation methods will give you a more neutral sight on topics. For a final sorting in a backlog you have to keep an eye on relations of the topics as well, e.g. topics that are the prerequisite for the implementation of another.

In addition, you run the risk of false planning with extensive prioritization, which no longer corresponds to the agile idea and thus to an iterative procedure. So be prepared to use this prioritization as an indicator and not as a planning forecast for the management.

Calculating HCF

First of all, the basic calculation is very similar to the one in WSJF. Just the wording is more clear for HCF: Need of a topic divided by the Expenses it causes. Those two factors can be described and estimated in detail by three variables each.

Basic formula of HCF

Do not “Overestimate”

The most important target of splitting up the single variables of need and expenses is to think about them and compare them. Often you will be able to stop here and just estimate a value for the two main factors. Estimating all single variables is very time consuming, but possible.

Need

The variables of need are very similar to the ones of Cost of delay in WSJF. Just the descriptions are sharpened to separate them clearly from the variables of the Expenses. Also, opportunity has moved to the front position of the wording to focus more on the positive outcome.

Variables of Need

Expenses

Variables of Expenses

There are three main differences to the WSJF method here:

  1. ‘Implementation Complexity’ is the new first variable. Instead of job size, this is something every team member will feel more comfortable with. This way, the team will not have the feeling to be forced to estimate the amount of time the topic will take. This might sound weird at first. But believe me, it will lead to a much more realistic estimation, especially for high level topics that are not clarified in detail!
  2. ‘Financial Costs’ are added. They can be relatively autonomous from the other Expenses.
  3. ‘Risk Remediation’ is added. WSJF only focuses on the Risk Reduction by implementing a topic. But also a new risk is created! Think for example of IT systems that could lead to new security aspects or simply the risk that comes with the future maintenance you have to do for a software feature. The important task of these variables is to prevent you from falling into what product leader and author Melissa Perri describes as the “Build Trap”.

Rating and Estimation

The rating can be simple and should differ from the typical Fibonacci-estimations of user stories. I like using the T-shirt-sizing technique:

  • S : 1
  • M : 2
  • L : 4
  • XL : 8
  • XXL : 16

For all six variables the scale is the same, because it is a relative comparison between the topics. For financial costs for example you could create an absolute matching with an exponential connection between the costs and the shirt size. The sizes can also easily be aligned with calculable numbers as described in the list.

Magic Estimation

To do the estimations, especially when there is a big amount of topics, I like to use Magic Estimation in multiple steps. Magic estimation is a fast way to estimate with only the needed discussions and with a relatively big group of people. This way one of my teams was able to collect, discuss and estimate 50+ topics in less than 3 hours combined.

The following example for a magic estimation is focused on estimating the big two factors with an eye on the single 6 variables. As mentioned before this is the way to go first. Only if necessary you could detail your estimations to the six variables!

Example of a HCF Magic Estimation

If you want to use the board, you can use the Miro Template including necessary rules and descriptions:

For the final calculation you can use the board or instead the excel file in the next chapter — this way the calculation is automated.

Formula and calculations

Example calculation

Of course it would be cool to be able to calculate in your task management tool or something similar. A past team of mine did this in ServiceNow. It was no easy task, but a labor relief.

For this example I did the calculation with Excel. It is important that you decide how to treat topics with the same calculated HCF value. Often this is done by feeling and that’s the way to go in my opinion, as this is one of your margins to play with. But of course you could define via the formula, whether you value need more or the expenses.

For the typical software development team with always more tasks than capacity, this would lead to a prioritization of the less expensive topics. That could cause problems later on. In this example I used a higher weight on expenses for example:

Example Calculation of Topics via HCF

Also download the template from here:

A more detailed example

As already mentioned there is not always the need to do the complete calculation, but always to think about all six variables. If you see a real value in calculating based on each variable, this is the way to go:

Complete formula of HCF

Aspects that could make it necessary to really do the detailed calculation in the end:

  • Discussion: Sometimes you are able do hold a discussion neutrally simply by objectifying its variables.
  • For a long list of topics it is sometimes actually easier to have the priority calculated. But, you have to really keep your list and values up to date and to make sure that your values are comparable.

Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.

--

--

I am a Methodologist and Technology-Enthusiast. I love handling complex challenges in Product Management and Organizational Development