The Science of Prioritization

Mountain_window_path_DuckPassIn my last article, I talked about the art of prioritization. I think those are good first steps to take when prioritizing your list, but it can be helpful to bring some objectivity to your prioritization as well. In this article, I’m going to share a couple of the calculations that we use to prioritize tasks mathematically.

Unless you are dealing with a pretty big job, taking these steps probably isn’t necessary. But if you are struggling to figure out which task to do first, using these methods can help.

Critical Path

This first method of prioritization relies on you having already identified your dependencies. Critical path analysis is typically used to identify how much time an overall project will take, and it also identifies which tasks absolutely have to be completed on time in order to not delay the overall project.

By working through the critical path method, we will know which tasks need to be started and finished first so that our overall project is not delayed.

Start by identifying all of the tasks that you need to complete. Ideally, you would break these down into their smallest steps, which will help with estimating them. In project management speak, this is typically referred to as a work breakdown structure (WBS).

Next, we are going to lay these out in order. It can be helpful to draw this by hand or using a diagramming application such as Microsoft Visio. Draw a box for each task, and then we’re going to have some additional boxes to contain estimates. Search for critical path method or PERT online for additional examples of what this diagram might look like. Here, I have an example of an activity on node diagram. It looks daunting at first, but it’s really quite simple.


As we draw other tasks, were going to identify work that has to be to done before other tasks, also known as dependencies. We are then going to estimate each of these tasks so we know how long the task will take. After that, it’s simple addition and subtraction.

We begin by walking through the diagram, from left to right, and adding up how long we think everything will take. In the diagram above, take a look at the box for task A. This box is divided into five boxes, and at the top left we have the starting day for the task. We can begin task A on day 1. Because we have estimated that task a will take 10 days to complete, we estimate that it will be completed on day 10, and that’s what we put in the box at the top right for task A.

Tasks B, F, and H are all dependent on task A. Because task A finished on day 10, the soonest any of these three tasks can begin is day 11. Note that for these three tasks, we indicate day 11 in the box at the top left. We then simply add the estimate for each of these tasks and that new number goes into the box at the top right.

We progress this way through all of our tasks, until we reach the far right and we have an idea of how many days total will be needed for a project. Based on the diagram above, 65 days are needed for this project. And we also now know the soonest any particular task could start.

If you are working through this exercise for a project where you are the only person working on it, then this is all a bit moot. In that instance, you are what is called a “constrained resource.” Every task will have to be completed after the preceding task because you can’t do two things at once. The same is true if a piece of equipment is required for multiple tasks and you only have one of those pieces of equipment. But it may still be helpful to know which tasks, given sufficient resources, would be critical.

So what about the boxes at the bottom of each task? Here, we are actually going to work backwards, and by working backwards through the chart, we can indicate the latest a task could start. This is how we identify which tasks are critical and which are not.

We start with task E and indicate in the box at the bottom right that it will be completed on day 65. We then work backwards using subtraction, and for task E it will complete at the same time as indicated it would start, or day 46. Just like before, the day a task would be completed would be in the bottom right while the day it begins is in the bottom left. The difference between the top and the bottom of the box is that, for the top we were working forward, and for the bottom we are working backwards.

This means that for tasks G, D, and H, the soonest they could begin is day 45. Again, we simply subtract their duration to get the answer for the box at the bottom left.

Note that task G has two dependencies, F and C. Because of this, the soonest it could start is the day after its last dependency is satisfied. When we worked forward, identifying the earliest start for each task, task G could begin on day 36 after task C was completed. Working backwards, note the difference between the top and bottom lines for tasks F and G.

When our top and bottom lines for a task are identical, this helps us identify a critical task. An example of this is task B. Compare this to a task where there is a difference between the top and bottom line such as task F. For task F, we would say that this task has some “slack.” For the overall project to be completed on time, task F could be started on day 11, but it doesn’t have to be started until day 26. This means we have 15 days of slack.

Meanwhile, for the overall project to be completed on time, task B must be started on day 11, and completed on day 30. If task B is completed on day 31, that will mean a delay in the overall project of one day. Subsequently, task B is a critical task, as are tasks C, D, and E. Note the red line connecting them indicating our critical path.

There are two pieces of information we can draw from this critical path chart. The first is that, for tasks with slack, we can either delay those tasks or slow down our work on them so that we can prioritize critical tasks and get them done sooner or faster. A delay to a critical tasks means a delay for the overall project, so we want to make sure that we absolutely get those tasks done on time or early if possible.

The second piece of information is what our priorities should be. Now that we know which tasks would delay our overall project, we know where we need to focus our attention. By looking at the chart above, you can see how this adds to the value of identifying dependencies. We have many dependencies in this overall project, but only four of them are on the critical path. Perhaps we can manage our schedule, shift resources, or prioritize by grouping to ensure these critical tasks are completed on time.

Weighted Shortest Job First (WSJF)

The second prioritization calculation I want to share with you today comes from Scaled Agile Framework (SAFe). SAFe is an agile management methodology, but today I just want to talk about one of its tools for prioritization.

By using the steps below, we can prioritize our list of tasks by Weighted Shortest Job First (WSJF). The weighting will be calculated using three values. The “shortest” piece of the acronym is dependent on our estimate of the overall task. Once we have our WSJF value, we can prioritize our list by WSJF. By working on tasks in this order, we are essentially prioritizing the fastest tasks to complete that have the greatest impact. Tasks that take a really long time and have lower impact will be prioritized further down the list.

Curious about estimation? Check out my article How to estimate like a pro.

For WSJF, we need to estimate three values:

  1. User-Business Value
  2. Time Criticality
  3. Risk Reduction-Opportunity Enablement Value (RR-OE)

More than likely, your estimation of these values will be subjective, but there are methods you can use for estimating that help make this more objective and accurate. For all three of these values, we are effectively attempting to size the delivery, or value, or impact of a task relative to other tasks. As with other estimates, smaller numbers either mean smaller value or impact, while larger numbers mean greater value, impact, or criticality.

For User-Business Value, we are attempting to estimate the value of this piece of work to both the customer and the business. You can do this on a 1 through 10 scale, or the Fibonacci scale using planning poker. So long as your scale is consistent between the different pieces of work you estimate, whatever you use should be fine. Relative to the other work we are doing, what is the User-Business Value of this piece of work we are estimating right now?

For Time Criticality, we are attempting to estimate how soon this piece of work needs to be done. Do we need to beat a competitor to market, or have something done by the end of the week for a meeting on Monday? Figuring out how this piece of work fits into our overall calendar and delivery requirements is the goal of the time criticality estimate.

Using WSJF, we are essentially prioritizing the tasks we can complete most quickly that will have the greatest impact.

The third value we need to estimate is a bit of a mouthful, and again it is largely subjective. Our goal here is to identify if there any secondary or tertiary benefits derived from this particular piece of work. The RR-OE value is again relative to the other pieces of work we are estimating. It helps us understand if this particular task either reduces risk or provides other opportunities within the business compared to other tasks that need to be completed. By way of example, while a particular task we are estimating might not be a dependency of other tasks, maybe completing it will help us do other things faster. If that is the case, we might want to give this a higher number so that it is weighted more the other tasks.

Now that we have these three values, we can calculate our Cost of Delay. This value helps us to understand the negative impact of putting a task lower on our list. The Cost of Delay is simply:

Cost of Delay = (User-Business Value) + (Time Criticality) + (RR-OE)

Cost of Delay is a helpful piece of information have, but on its own it doesn’t do much for us. We are going to combine it with our estimate for how complex a task is or how long it will take, and that will be our WSJF value.

This means, of course, that you must have already estimated your tasks, or you need to do so before you can calculate WSJF. To get our WSJF, we simply divide Cost of Delay by the estimate.

WSJF = Cost of Delay / Job Size (Estimate)

Now that we have our WSJF, we can prioritize our tasks based on it. This objective method of looking at everything we need to get done will help us to deliver the largest value pieces of work soonest.


As I said at the beginning, it is unlikely that you would need either of these methods for your day-to-day task list or for managing household projects. But for larger projects, particularly ones that span months or have multiple complex tasks, bringing some objectivity to your checklist can be really helpful.

Remember to stay consistent with your estimation methods for your different tasks. Whether you use story points or hours, a linear or Fibonacci sequence of numbers, or some other method unique to your organization, the key is consistency.

Do you have a different mathematical approach that you like to use when prioritizing tasks? Please share your thoughts in the comments below, because I would love to hear about them!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.