This article is part of the Challenges with estimations and possible solutions series.

Imagine the following: someone from the business comes forward to the team with a proposal and after an explanation asks: "So, how long would it cost to make it?"

For such a seemingly simple question, I believe there are a couple of things that need to be unpacked before answering this question.

"Just give me a number..."

Estimations should be considered akin to a random variable. That means the estimate represents some value with some expectable variance. When being pressured to give just a single value, you will need to understand the context of how this value will be used.

Often that context is that someone is thinking about establishing a budget for some project. In such a context, the question for an estimate should be reframed into 'How much time would you recommend, such that you have say an 80% confidence window that it'll be within budget?'. If you know the Probability Density Function that describes your estimated variable, this is something that can be computed. If you do not, you'll need some sense of the spread you have in that random variable to deal with contingencies. A rule of thumb I've heard people mention is to double or triple the original estimate if you really have no clue, but I would consider that a last resort. Within this context, answering it with 'on average' therefore tends not to be good enough, as the average is basically a 50% confidence window!

Another common case is where someone would like to determine if it's worth doing this project from a 'return on investment perspective. I would urge you to resist the temptation to give only 1 single value. Either give a range ("We believe it's reasonable to expect this takes between 2 weeks and 4 weeks with this team.") or worst/nominal/best case scenario ("In the best case, we believe we could be done within 1.5 weeks. However, in the worst case, we suspect various problems could make it take up to 7 weeks to sort it out. But if we expect only some set-backs and that those a reasonably well managed, it'll be around 3 weeks."). When assessing return on investment, I believe understanding the underlying risk is important and therefore being transparent about the expectable ranges is important.

Ambiguity of cost

This question is ambiguous in multiple ways.

There is a relationship between how long a piece of work is going to take and how many resources are committed to that project. Both aspects can be interpreted as a statement of cost. Luckily this confusion is quickly resolved because the units of measure are different: people/machines versus time.

However scoping can also cause ambiguity, where the question is being answered incorrectly without the person asking the question realising it. Does the project include or exclude legal arrangements? Does the project include or exclude testing? Does the project include or exclude responding to feedback? Is the whole team committed to just this project, or spread across multiple? When the code is done according to the developer or when the feature is deployed and available to all users in production?
Misalignment on these will result in an unsatisfactory answer, yet no-one might realise this is happening.