Why Estimate?

In a previous blog post I discussed the different options to estimate a ticket and why I still prefer using story points. It is evident that estimating is difficult and comes with a lot of caveats without really giving us any guarantee. All of this may make one wonder why we even estimate at all.

Don't get me wrong, estimating is a very natural thing to do. As soon as you start working on a task, you start estimation how long it will take, even when nobody asked about it. You just want to know so you can schedule your day or week. In business it isn't any different. You want to know when a certain feature will be done so it can be released. You may need to know this information to communicate it to users, or there may be a hard deadline which you have to meet.

The latter case can be very tricky, as having such a hard deadline can easily influence the estimation in order to make it fit. But assuming that doesn't happen, having an estimate gives you a better feeling whether or not the deadline can be met. There is however a big caveat, having an estimate still doesn't give you any guarantee, it gives you a certain probability, and that is what most people do wrong. They takes estimates, put them all together and come to a yes/no conclusion.

This is one reason why estimating is difficult, you have to deal with uncertainty and you have to interpret the estimations correctly. That is why, when estimating, it is advised to have 3 different estimates for worst, average and best cases. This allows for a more correct interpretation and better conclusion.

It is clear that estimation can have value when used for planning for the future. I have however seen many projects where the planning didn't matter that much. A new version would be released when all features were implemented, or the new version would be released even if they were missing and slowly added. In this kind of project, what is the point of putting numbers on things when the numbers don't add any value? There is no point in keeping track of things for the sake of keeping track, you are just waiting time.

In a scrum setting, estimating is essential to know what you can do in a single iteration. I understand this, but again, this only makes sense if you actually plan on releasing something at the end of the iteration. With the current state of web applications, why are you waiting for an artificial point to release a new version? Why don't you release whenever a new feature is ready? And what do you do if some feature that was planned during the iteration isn't done?

In this fast moving world, there often isn't much to gain from having a detailed plan for the next year, things change fast and you have to be able to adapt. I feel there is much more value in releasing often and only looking ahead a few weeks at most. Don't get me wrong, it is vital that you have a clear goal or target for your application, but that is on the functional level, and shouldn't rely on a fixed timeline. Let your goal be determined by your users, and the only way to know what they really want is to receive their feedback often.

To come to some sort of conclusion: I wouldn't estimate for the sake of having estimates. If you need to have an indicator for when a certain set of features will be ready, do estimate things, but don't make any guarantees as things are likely to evolve and change. The more ahead in the future you are trying to plan, the less likely your planning will stand. Don't be afraid to get rid of estimations and save yourself some useful development time. The time it may take to estimate a ticket could also be spent on implementing it.