A recent popular tweet made me worry because people might agree with it for the wrong reason.
Without calling out people, all of it boils down to this quote:
Don't trust developer estimates.
People saying it and agreeing with it is a sign of the problem. It paints a picture of a developer being a person you cannot trust and makes less experienced folks feel bad.
The issue spans beyond twitter. Many books and engineers talk about it a lot. I bet somebody gave you the advice to double or triple your estimates as a rule of thumb.
Everyone involved in software projects has to stop ignoring the fact that an estimate implies uncertainty.
Dealing with uncertainty.
Reality changes every day. What worked a month ago is not guaranteed to bring the same results this month - especially in the modern world.
What we do carries a risk. We should embrace the fact that we cannot eradicate it and focus on reducing it instead.
If the estimation is uncertain, then it does not reflect reality - be it story points or actual hours. Why would you want to bet on it then?
Focus on the objective. I don't mean finishing user story A, B, and C. Don't confuse it with a task. Think of it more like the outcome you want to reach. You might want to improve conversion in a specific channel, help customers do X, or assess the viability of a technology.
If your measurements had proven that something you do is not working as expected, then it is time to take learnings, apply them, and continue what you are doing or pivot.
Rinse and repeat until you achieve your desired outcome.
Dealing with time.
Time exists, we can't deny that, but estimate still means nothing when it comes to delivering actual value.
I am not saying that you should always take your sweet time. You still have to impose limits on yourself.
Give yourself a time frame for contribution. Be it a two-week sprint goal or a quarterly objective measured by key results.
You still have to take your organization's and team's values into consideration. Some might find unpolished look acceptable. Others might not.
Combining the limits with clear objectives and values can yield results faster. They might not be what you have expected, but it is better to learn about it sooner than later.
Some might say that they need a time estimate so they can put pressure on themselves or their team. More sensible people consider the unpredictable nature of estimation and double, or triple, them just in case.
There is a problem with this mindset. It switches the focus from delivering value to getting specific things done on time. Time spent is not directly proportional to the value.
You don't reduce risk by increasing the estimated time. You are reducing risk by validating your assumptions often instead.
If you are worried about how much time work will take, focus on reducing the friction in your team instead.
What if they still expect you to give an estimate.
If you agree with the organization's reasoning or are willing to accept it, then go for it.
If you are not, then you can try influencing people around you - which is a great skill to learn - and be good friends with them or consider looking for new opportunities.
Top comments (3)
An estimate is like a weather forecast - you can read about having sunny weather in the morning paper but you could get drenched in the rain in the afternoon. Estimates have to be revised based on new findings.
They definitely need an adjustment when you already have them and it is expected to use them. Imagine how much time you can save when estimation is not a part of daily work.
Estimation is a waste of time. Time that could be spent getting on with the task. Task breakdowns are similarly pointless as they very rarely reflect the reality of how a task actually plays out