Prioritizing projects and tasks with minimum loss of time and money

Last week, I was so fortunate to attend a marvelous talk by Donald Reinertsen on a amazingly effective approach for prioritizing projects within an agile organization (and which is part of SAFe). Most managers will tend to prioritize their projects based on non-quantifiable attributes such as the strategic importance of a project or the risk of loosing a contract. But if you have a multitude of those projects, all equally important, how do you make a decision on what project should be done first? In his opinion, prioritization should happen on a principle named Weighted Shortest Job First. In this principle two figures are of upmost important:

1. The duration of the project
2. The cost of delaying that project

By dividing the former by the latter, you get the weighted value on which you prioritize. Consider for example three projects, A, B and C, all with the same cost of delay but with varying lengths. If you would put them on a graph like the picture below shows, it becomes pretty obvious which project should be done first. So although my first instinct would be to try to get that big project out of the way first, that's actually the least economical thing to do. And it doesn't matter whether you define your units in weeks, months, story points or cows, as long as you don't compare apples and oranges.

Now how do you deal with those strategic projects I started this post with? You still need a way to quantify those. One way is to try to estimate for how much money completing such a strategic project will enable other projects. Another possibility is to ask the involves stakeholder on how much money he or she is willing to pay for the advantage of starting this project first.

And what about projects you really can't predict the length of? Well, in that case, Donald recommends allocating fixed chunks of capacity to a project. When that chunk of capacity expires, you simply put that project back in your queue and reprioritize. This might work particularly well with technical innovation projects where you need a couple of those chunks to be able to reliably estimate the remainder of the work. And guess what you need to do when you have that information…

So, one particular question I tried to get an answer on is how this all applies to user story prioritization. Over the years, I have had many discussions on stories needed to bring down technical debt or architectural changes needed to handle non-functional requirements. Quite often, and despite of my efforts to convince the product owner of their value, I get overruled and other features get priority. By trying to estimate the cost of delay for those technical stories as well as their length and comparing those to the weighted values of the functional stories, you might make a better chance of convincing the product owner. You could even use this within the team to help determining whether taking a shortcut is worth the trouble to meet a deadline early. I haven't tried this myself, so I don't know if this would really work, but I'm sure going to try that soon. Anyway, if you want to learn more about the scientific aspects of this technique, I recommend reading the original article on the SAFe website.

So how do you do prioritize projects, tasks and technical debt? Let me know by commenting below or tweeting me at @ddoomen.