Last update: 23/04/2019 14:42

The L(i)VID Formula [1]

The L(i)VID Formula ― Halina Krasowska

Agility: the power of moving quickly and easily. Ability to think and draw conclusions quickly; intellectual acuity, this is what we need to bear in mind when we speak about "Agile Methods"!

Now think about the way estimates are requested, think about the way people make them, think about the way it is required to refine them in multiple rounds, think about the way they serve "negotiations/bargains", think of how the value of a project is calculated, evaluated or forged, think … Are we really agile in these matters? I don't think we are!

We've outgrown all that now and it's to us to update the unwritten rules of Project Portfolio Management, of Project Management and of Product Development. It's up to us to change the rules of how agility should be embraced when dealing with all the processes we must follow.

With this post we shall introduce a surprising way to prioritize projects/initiatives in minutes instead of hours or even days or weeks! That's a way —not THE way— to become agile in that matter. It's LEAN because it eliminates a lot of waste.

Terrible Estimators

We are terrible estimators. If we must quantify work to be done we're often off a factor of 2 or 3. This gives somewhat ground to these wise persons who multiply estimates by pi.

Pretending the contrary would boil down to pretending we know the future, or that at least we can account for uncertainty by some magical math. This is not the case. Unfortunately.

The "Estimates" Syndrome

Because we know we are terrible at estimates we want to pay more attention to it … we want to detail them. Only this does not help either, or at least gives no other sort of predictability. At the end of the project we're still deviating from what was first estimated, in money and in time. So for the next ones in the row, we want to be even more precise and scrupulous and this requires … more money and more time, which are actually stolen from on-going projects due to the very nature of how estimates are conducted: via work interruptions!

Exit (precise) estimates. Long Live Ballpark Estimates!

Estimates should exit the picture or at least exit the picture the way we conduct them as of today in large organizations like banks, insurance companies, governmental bodies, …

It reminds me my education years where my marketing professor, Paul Van Vracem, taught us to conduct market studies before launching a product. Sure! That's great idea to check whether there is a place for the product on the market but what if the cost of failure is less than the cost of the market study. What if failing is cheaper (and bears low long-term consequences)?

That is exactly the point with estimates. We persist delivering the most accurate estimates possible losing from sight how much it costs to produce them. Sometimes going ahead without any further question is better and cheaper: simply do it! (if consequences of failure are low). That's for the spirit. Reality is a bit different though.

Estimates are still needed but we must rethink the way we produce them and we need to rethink the way we evaluate the value of what we propose to build (project or product does not matter): we need to forsake the illusion of accuracy as it simply does not add any bit of confidence. Gross estimates are more than enough, and they are far less costly to produce.

Estimates Are Part of Project Prioritization

It is not the purpose of this post to see how ballpark estimates are constructed. We take it from the point where we already have these ballpark estimates!

Now when multiple projects need to be prioritized we often resort on estimates to see what projects we can take. This is all normal. After all, we're not living in a limitless world, at least not me.

What's the problem with estimates in the prioritization exercise then? According to me, estimates are often the primary factor of prioritization, not to say the only one, it even outshines the benefits one expects from the project/product, and I can't stop myself from thinking that this is wrong! Having estimates overshadowing value, sense of urgency, importance or strategy is simply not the way to go [2] .

The prioritization exercise should be played differently to be able to quickly sort the projects that we want to execute from the ones that must remain in the backlog (for now). That's where the L(i)VID formula enters the scene.

L(i)VID (pronounce livid)

This formula computes project/initiative prioritization based on 4 factors: L, V, I, D … hence the name of the formula. L stands for Labor, V for Value, I for Importance/Urgency and D for launch Date.

The output of the formula is a number between 1 and infinite. Often, infinity is limited to 50 [3] . The higher the result, the higher the priority! Projects/initiatives are then engaged based on this automatic priority.


The formula has three main objectives:

  1. Speed and Simplicity
  2. Transparency
  3. Sequencing

Speed and Simplicity

How fast the prioritization exercise can take place is key. Having a formula that executes in about 10 milliseconds makes it possible to prioritize an entire backlog in seconds instead of hours, days or weeks. Think of it: reprioritization of a 1000 projects backlog performed in 10 seconds! This is speed and simplicity.


What do we have in mind here? We want to avoid lobbying! By having a public formula, very comprehensive for all to see, not giving grip to bargain, we eliminate the need for project lobbying (something that often happens in large organizations). This is transparency.


The formula does not produce weighting; it produces sequencing, order and priority. In other terms a L(i)VID of 10 does not mean 2 times more important than a L(i)VID of 5; it means that the project yielding a L(i)VID of 10 should be taken before a project that yields 5. It is as simple as that. This is what I call sequence.

Principles and Factors

L, V, I, D: L stands for Labor, V for Value, I for Importance/Urgency and D for launch Date. I pretend that 4 factors are enough to prioritize projects/initiatives [4] .

L = Labor

This factor is the one where estimates come into play. In the formula, it must be expressed in mdays.

Now, having said that L is expressed in mdays does not mean that I recommend a precise, to the hour, calculation of the work involved in an initiative. The way I suggest to use this parameter is to have the team which is approached for the project to provide rough estimates and to use this as a kind of loose budget. Another approach would have to get the Business people to define the money they are ready to spend to finance the project/initiative. Anything that respect simplicity and responsibility will do!

V = Value

There is much to be said about value (see the Business Value article for some detailed considerations about value [5] ). In a nutshell, it is my personal belief that 'value' is in flux and cannot be divised once for all precisely for all contexts. When a Product Owner for example is told to prioritize items based on their value, I think that this is more easily said than done. What is value precisely? What kind of value are we talking about? Business Value? Customer Value? User Value? Stakeholder Value? Shareholder Value? Simply Value? And how the hell you evaluate it? My answer is simple: there is no simple answer! Value is a matter of multidimensional interpretation in the context of the organization. Period!

Stop filling these long excel sheets by which you tend to fool yourself about the benefits of your project/epic/feature/initiative/ambition (would that be via NPV, ROI, MVA, SVA, …). Everybody does the same: inflate the importance of the project, maximizing the benefits of it and … never check the real market outcomes with what they heralded some day, when their target was to get the project accepted! [6]

What I propose is something very similar to Planning Poker based on the (modified) Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144. In the prioritization meeting electors vote for the value of the projects in a very similar way stories get estimated in agile methods! This should take minutes instead of days. Why do I think that this is at least a zillion times better than the current methods? For at least three reasons. Firstly, it is way simpler. Secondly, the vote of the so-called electors is a way to express their interpretation of what the value of the project/product/initiative is for the organization (instead of falsely declare that we, as an organization, know for sure what the value is, or will be (which is another dimension of the value, one that unfolds with time). Thirdly, it has never produced less predictability than detailed estimates!

I = Importance (urgency)

Projects can be of normal urgency (I=1), can be forced (I=5) or can be of legal obligation (I=10) (feel free to use any intermediary scale of scores).

D = desired launch Date

The desired launch date is expressed in the YYYYMMDD format. What counts here is more the daily work than the desired launch date (number of days between now and the desired launch date). This explains why the formula renders different results every day, every hour, as the number of days to build the solution diminishes (all other parameters remaining unchanged).

The formula introduces a bias here: as soon as the estimated workload per day exceeds 7md, it means that the project will incur additional interpersonal communication (IPI - Interpersonal Index). The higher it is, the more risky the project is because it requires more alignment between the members of the team. The formula applies a given bias via an exponential calculation.


Here is a list of examples. Click on each link to see the outcome of the L(i)VID formula at the moment you click:

L(i)VID Code in PHP

function Livid( $L,$V,$I,$D )
if ( $L <= 0 )
return ( -1 );

if ( STR_Empty( $D ) )
return ( -1 );

$tNow           = time();
$tLaunchDate    = TIM_MakeInt( $D );

if ( $tLaunchDate <= $tNow )
return ( -1 );

$fDays          = abs( $tNow - $tLaunchDate ) / 86400;
$fWorkingDays   = ( $fDays * 5 ) / 7;
$fEffortPerDay  = $L / $fWorkingDays;

$iTeam          = ceil( $L / $fDays );

$fContingency   = 0;

/* If team required > 7 persons ...
add 17 % contingency */
if ( $fEffortPerDay > 7 )
$fFactor        = ceil( $fEffortPerDay / 7 );
$fContingency   = pow( 1.17,$fFactor / 1.17 );
$fEffortPerDay *= $fContingency;

$fEffortPerDay = round( $fEffortPerDay,3 );

/* Even if no value is given to the project
assign minimum one */
if ( $V < 1 )
$V = 1;

/* Check Importance/Urgency (1 = normal; 5 = forced;
10 = legal) */
if ( $I <= 1 )
    $I = 1;
elseif ( $I >= 10 )
    $I = 10;
    $I = 5;

if ( ( $x = $V * $I * $fEffortPerDay ) > exp(1) )
$fPrioritisation = round( log( $x ),3 );
$x = log( $x );

if     ( $x <= -8   ) { $fPrioritisation = 0.1;    }
elseif ( $x <= -6   ) { $fPrioritisation = 0.153;  }
elseif ( $x <= -5.5 ) { $fPrioritisation = 0.207;  }
elseif ( $x <= -4   ) { $fPrioritisation = 0.26;   }
elseif ( $x <= -3.3 ) { $fPrioritisation = 0.313;  }
elseif ( $x <= -2.6 ) { $fPrioritisation = 0.367;  }
elseif ( $x <= -1.7 ) { $fPrioritisation = 0.42;   }
elseif ( $x <= -1   ) { $fPrioritisation = 0.473;  }
elseif ( $x <= -0.6 ) { $fPrioritisation = 0.527;  }
elseif ( $x <= -0.3 ) { $fPrioritisation = 0.58;   }
elseif ( $x <= 0    ) { $fPrioritisation = 0.633;  }
elseif ( $x <= 0.3  ) { $fPrioritisation = 0.687;  }
elseif ( $x <= 0.6  ) { $fPrioritisation = 0.74;   }
elseif ( $x <= 0.75 ) { $fPrioritisation = 0.793;  }
elseif ( $x <= 0.9  ) { $fPrioritisation = 0.847;  }
else                  { $fPrioritisation = 0.9;    }

return ( $fPrioritisation );

function STR_Empty( $szStr )
return ( ( ! $szStr ) || ( @strlen( $szStr ) === 0 ) );

function TIM_MakeInt( $szDTOS )
$iRetVal = -1;                          /* Default return va;lue of the function */

if ( ! STR_Empty( $szDTOS ) )           /* If parameter OK */
$i = strtotime( $szDTOS );          /* Make this a time value */

if ( is_numeric( $i ) )             /* If numeric value */
    $iRetVal = (int) $i;            /* Turn it to an integer */
}   /* if ( is_numeric( $i ) ) */
}   /* if ( ! STR_Empty( $szDTOS ) ) */

return ( $iRetVal );                    /* Return result to caller */


  1. Estimates should be constructed and collected more easily. Ballpark estimates seem to be enough.
  2. Estimates play a important role in project prioritization, too important in my humble opinion, outshining a much more precious though difficult one: value. This is wrong pattern even though estimates are a key factor.
  3. The L(i)VID helps prioritize projects/initiatives versus one another, not to measure their importrance. An entire portfolio can be prioritized in a fraction of a second in all transparency.


[1] … This article first appeared on I have made recent adaptations to it to reflect my latest thoughts about this topic

[2] … I have witnessed this in many companies that are cost-oriented instead of being value-oriented. Being cost-oriented is remarkably simpler! (It is much harder to measure value than it is to measure cost. Cost-driven organizations have chosen the short-term and easy exercise.)

[3] … The highest number I ever got was a simulation of a 1 million md project, having the highest value possible and considered a legal project: 109.16

[4] … This happened after an intense introspection. I have for example long hesitated to take Risks into account after rejecting the idea

[5] … 27-07-16 12:31:57: the article is still under construction

[6] … Inflating the profits and lowering the costs are two key activities that often take place before projects can be started

[7] … The result is very much dependent on the time you run the formula! Click the link to get the CURRENT return value. This remark holds for all results presented here.

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X