DEV Community

Discussion on: Estimation is not impossible

Collapse
 
curiousdev profile image
CuriousDev • Edited

Estimation can have a purpose, but to make any sense you need to know what exactly you are estimating.
You should know, if you are estimating e.g. with time or complexity.
If your team consists of members with different experience and focuses, it makes a difference, if you are estimating with certain people in mind or not.
Also knowledge of the business it not necessarily what you need, knowledge with the technology and solving problems with it are important.
The part with historical data makes sense, if you have enough data and are doing similar work with similar team members.

Collapse
 
fjones profile image
FJones

Estimating complexity always sounds good on paper - after all, it's independent of developer skill, and considers the work involved more. But I have found it to be a double-edged sword.

For one, if you have substantial skill differences on the team, it does prove to be a depressing force for the weaker members, as they are inevitably compared to the stronger members, even if the difference stems from something as simple as experience.
The other problem is that you need to estimate with a thorough understanding of the problem, which can often be difficult. Adding a research modifier to resolve that only muddies the estimate, so you end up with either very clear solution plans before ever estimating (which leads to tension when it comes to implementation), or very difficult and often very wrong estimates when assumptions don't line up with the reality of the problem.

I tend to estimate for the weakest team member, but in terms of "how long should it take?", translated to a bit of a blend between time and complexity estimates. If a task turns out to be a lot more intensive than anticipated, with this framework it generally implies flaws in the codebase to be resolved - bad DX leading to slow resolution, essentially.

Usually, I'm bang on the money with my worst-case estimates (when problems do arise), but the recorded estimate tends to drift a bit between worst and best. It's far from ideal, but it provides better feedback to stakeholders than any other method I've found so far.