Estimations

Estimations is one of those topics that keeps me bouncing from one camp to another. On one hand estimations have great side effects, even if the time is off. It allows a team to breakdown a task and think about each individual piece. It’s a theoretical framework from which we can better understand the pieces that make the whole. But it’s just an exercise and it often collides with reality. Edge cases can and will be missed, or sometimes even entire flows. So it’s an imperfect way of understanding the feature, without actually building it.

When asking for an estimation, the first question one should ask to themselves is: how rigorous, or close, should the estimation be? If the answer is for it to be as close as possible to reality, you either a) have a team that already did something similar. So the odds of getting it right are high, or b) the team will spend enough time estimating, breaking it apart and prototyping, that it will likely match the time it would take to build the feature anyway. Estimations for someone that a) never did the feature or b) is not intimately familiar with the system within which the feature will live on is pure fantasy. To reiterate, the engineers building the feature need to have built something similar in the past and know the corners of the system where it will be implemented. This should give you enough confidence in the time they give you.

There’s a good chance that a team doesn’t have all the necessary tools to give an estimation - that’s okay and pretty common. What you can do instead is a transpose. And you have two options. Time is fixed, so estimations don’t matter. This is typically called a time-boxed feature. What tends to happen is to cut so much of a feature that you get a minimum viable product (MVP). Pieces are discarded, in order to meet the agreed end date. That’s a good thing, because it allows you to test the waters faster and get a feeling if what you are building resonates with customers. The other thing you can do is weight priorities. You have to ask yourself if there’s anything more urgent to build than what you are asking an estimation for. If there isn’t, then the estimation doesn’t matter anyway. The team should be focused on getting the feature out, since it’s the most important thing.

In both cases, which are the most healthy, estimations are inconsequential.