Cost estimating methods have been around for a long time. The current processes found in agile use a *points* system, sometimes a Fibonacci series to *bin* the values of the *points*.

The challenge with this approach is the estimate in agile is not monetized so we can't really tell if the Total Allocated Budget (TAB) is sufficient for the project at any point in time, unless the capacity for and the quality of the ourcomes is *steady - *that is Level of Effort.

With the LOE approach, the *capacity for work* is the critical measurement needed for estimating the cost at completion. As well continuous updating of this capacity for work is needed and correctly done on good agile projects.

But there are other issues with this LOE approach on larger projects:

- Do we know the variances in the capacity for work and how those variances will impact the final Cost at Completion?
- Do we know the interdependencies between the various work products and how they impact the final cost?
- Do we know the Aleatory uncertainty - the natural occurrence that can't be
*fixed*and has to have*margin*. - Do we know the Epistemic uncertainty - the event based risks that need a risk handling plan?

So the examples like that found at Projects @ Work, don't really consider any of the underlying uncertainties in estimating. Without the next level down - statistically adjusted estimates of the work effort, the capacity for work, the quality of that work, and the interdependencies between those work activities and their products, the simple and maybe even simple minded approaches to estimating have limits to scaling.

This is one of those topics where everyone is right in some way, depending on the domain, context in the domain, and scale of that domain. As agile enters the larger acquisition community, where we're spending other peoples money - maybe 100's of millions of dollars, care needs to be taken when applying un-monetized, non-probabilistic, non-joint probability (cross correlations between work element) and non-stochastic forecasting models. The *real* world is not that simple.