There's proper math behind it, but the simple rule of thumb is: more time we spend on estimation, more accurate the estimation is.
The minimal estimation takes almost 0 time and has almost 0 value — we don't know the upcoming unknowns and uncertainty, and we have no clue of the task complexity.
And the ideal estimation can be done just measuring how much time it actually takes us to complete the task — all the unknowns are resolved, uncertainties became certainties, and the task complexity is not only known, but successfully dealt with.
Usually people choose some form of estimation from the range between ideal and minimal, paying some price for some prognosis accuracy.
But how do they determine the level of prognosis' accuracy they are willing to pay the estimation price for?
It seems that usually people don’t choose the accuracy, but just bluntly do estimations :(
But why are they investing money in buying the prognosis in the first place?
I've asked managers a lot about this, here's a list of usual reasons for investing into estimation:
- to see team load/capacity
- public tender requires estimates
- manager needs to know when the feature will be done / manager needs to understand how much the feature costs / manager needs to be able to choose which feature to do first
I honestly could not figure out how team load or capacity yields a necessity to gather estimates.
Companies create value for their clients and support features that clients value.
The request for the value might come from client themselves, from product manager, customer support. Also the request for support might come as a request to fix a defect.
If the team receives more requests than it can process, requests are logged, forming a backlog.
If the team is not delivering enough (the backlog accumulates more requests for value than the team process), there are a few ways to improve the situation:
- request less
- check the information flow in the system and optimise the processes
- hire more people
It is important to perform these activities in this particular order:
-
if hypotheses quality is improved and ‘better’ features come from product managers, there’s less need to optimise the information flow in development processes
-
if information loss is decreased in the development processes and less waste is generated, existing team can do more and there’s no need to hire more people
-
hiring more people is the last and the least effective way of improving team performance as increasing team members count yields higher management complexity and costs
In any case I can’t see how ‘seeing team productivity’ is connected with estimations — team productivity is ‘how much value we are bringing to clients’, not ‘how often our prognosis is successful’.
➖ investing in estimations is not rationalised
The time and budget constraints are external to the company so if the company needs this contract it has to comply.
The company has to decide if producing the required system within required budget and time is economically beneficial.
➕ investing in estimations is rationalised
This request is very abstract.
Most common reasons for this request that I’ve heard are:
- marketing campaign starts on the X date and we need to understand if the team manages to build and launch a feature
- an external event with set date emerged (for example, FIFA world cup) and managers need to understand if certain features can be launched on time
Marketing team works alongside IT team for the same company.
The whole company goal is to make client happier.
So why can’t these teams collaborate in a high-trust environment?
Can marketing predict exact number of sales they will generate for a certain budget (essentially, the outcome)?
If not, why does the IT team need to predict the outcome of their work?
Compare these two scenarios:
- IT team produces some value for the clients and marketing team starts advertising this new value to potential and existing clients
- Marketing team dictates the IT team ‘the advertising campaign will be launched on X date, you must be on time’.
To me it looks that the first scenario doesn’t provoke quality decrease (due to rushing) and also doesn’t require spending resources on estimation.
➖ investing in estimations is not rationalised
There might occur an external event which makes the company require estimation from the IT team.
For example, the country wins an opportunity to hold UEFA championship. Then the company needs to invest time in estimating a certain set of features to make sure it’s worthy to invest money into building those features so that they are delivered before the UEFA championshop.
If the result of estimation shows that even the minimum minimorum of features can’t be built on time, the company will decide now to even start building these features.
There’s a good question though — how often do events like this occur?
In the example of UEFA championship there are two things to weigh and compare:
- amount of resources required to estimate + amount of resources required for ensuring the project is done on time
- the probability of country winning the UEFA championship
If the probability (2) is high, it might be beneficial to bid on it and prepare the software in advance and just turn it on when needed.
➕/➖ not sure if estimation is rationalised
There usually are two reasons for this particular request:
- manager wants to compare features based on their cost
- manager wants to understand if a certain feature ‘is worth it’
These reasons are deeply intervened.
First, before any development estimation is done, product ‘estimation’ needs to be reviewed.
If a manager ‘just tells to build the feature’ with no prediction on how the feature will benefit the clients and the company, there’s absolutely no need to do any ‘estimation’ of development.
In this scenario manager just throws unsupported guesses to the development team – pure leap of faith.
So in this scenario manager doesn’t get any estimations — manager first need to explain why the company needs the feature, i.e. why the manager is going to spend development team time and effort.
If our manager does provide economical rationalisation (i.e. product value estimation) for the feature, next step is to check how accurate their estimations were.
If manager’s previous estimation accuracy is low, there’s no need to do development estimation, it is a ‘leap of faith’ anyway.
Here’s an illustration:
Let’s say that a Product Manager comes up with three features: Square, Circle and Triangle.
Product Manager provides the following profit estimation:
+-----------+-------------+
| feature | estimate |
+-----------+-------------+
| Square | $50k-$90k |
| Circle | $150k-$200k |
| Triangle | $300k-$400k |
+-------------------------+
Dev team gives the following estimations for time the team will spend on the delivering features:
+-----------+-----------+
| feature | estimate |
+-----------+-----------+
| Square | 10-40d |
| Circle | 15-30d |
| Triangle | 20-24d |
+-----------+-----------+
Built together with team time converted to money (1d to $1k for simplicity):
+-----------+---------------+------------+
| feature | revenue est. | cost est. |
+-----------+---------------+------------+
| Square | $50k-$90k | $10k-$40k |
| Circle | $150k-$200k | $15k-$30k |
| Triangle | $300k-$400k | $20k-$24k |
+-----------+---------------+------------+
It seems that all these three features were well-worth to do, according to our estimations:
- Square will yield at least $10k in the worst case scenario
- Circle will yield at least $120k in the worst case scenario
- Triangle will yield at least $276k in the worst case scenario
Now let's see what happened when the features Square, Circle and Triangle got developed and delivered to the clients:
+-----------+----------------------------+-------------------------+
| feature | revenue result | cost result |
+-----------+----------------------------+-------------------------+
| Square | $90k (from $50k-$90k) | $13k (from $10k-$40k) |
| Circle | $200k (from $150k-$200k) | $30k (from $15k-$30k) |
| Triangle | $30k (from $300k-$400k) | $40k (from $20k-$24k) |
+-----------+----------------------------+-------------------------+
As we can see, a few estimations were wrong.
- Square yielded $57k.
- Circle yielded $170k.
- Triangle yielded loss of $10k.
Well, real life is tough, estimations fail lots of the times.
But here's what's important: it makes more sense optimising the quality of estimation on the left, on the product side.
There's another conclusion: there's no point in doing estimations in IT if PM doesn't have a decent estimation quality (and a proven record of providing estimates of decent quality).
It’s also quite obvious that comparing any features on their cost only makes pretty much no sense as well — it makes sense only in the case when PM’s revenue estimation quality of prognosis is ridiculously high :)
➖ investing in estimations is not rationalised
We discussed price and value of estimations, now to the side effects, chief among them being:
- estimations become promises
- promises become deadlines
- deadlines bring stress
- deadlines bring coordination issues
Human beings are innately irrational. We are affected by multiple cognitive biases, so even if we don’t want to ‘take prognosis as a promise’, chances are we will. And so do our managers.
We ourselves think that if we estimate, we promise.
Our managers think that if we estimate, we promise.
What happens when we don’t get what we were estimated promised? We are upset. Both with the fact and with the person that ‘let us down’. We might even make this person feel guilty.
What happens when we can’t do what we estimated promised? We are upset. Both with the fact and that we ‘let down’ the manager or our team. We might even feel guilty.
We can fight these feelings, sure. We can force ourselves to think ‘rationally’. But the fight takes effort. And this fight’s eternal.
Overcoming these negative psychological issues and social dynamics triggered by guilt and failed promises is hard.
This is just another side effect of estimations.
There’s another big side effect of estimations/deadlines: almost inavoidable efforts coordination based on estimates.
Dysfunctional tools like Gannt charts are still very popular, and if anyone provides estimations, it’s so tempting to align those estimates and never think on the uncertainty of the world we live in.
TBC