paint-brush
Estimation only tells you the past, not the futureby@virtualgill
239 reads

Estimation only tells you the past, not the future

by Gillian ArmstrongAugust 26th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Estimation is an exercise in the illusion of control. It allows us to believe we can accurately plan for the future. We estimate because we hate uncertainty.
featured image - Estimation only tells you the past, not the future
Gillian Armstrong HackerNoon profile picture

Estimation is an exercise in the illusion of control. It allows us to believe we can accurately plan for the future. We estimate because we hate uncertainty.

Here’s the problem – it isn’t possible to know how long something you have never done before will take. The only thing you could somewhat accurately estimate is something that is exactly the same as something done multiple times before. If that’s the case, and for some reason we aren’t automating that, then my slow descent into madness will start to throw it off anyway. Estimation can only be based on the past, but the present is already different, and the future is always uncertain no matter how much we wish it wasn’t.

You can spend the time estimating instead of implementing, but it won’t actually change how long things will take to do in reality. If you do happen to have the power to warp time and space to change how long something will take to do by writing a number on it, then do yourself and your team a favour, and put a 1 on everything. Alternatively if you have the power to predict the future absolutely accurately, then there are many lucrative choices for you. Don’t waste that power story pointing.

Are we just throwing out all the processes then?

I did hesitate here, but I’m going to go with ‘no’. There is actually one that is critical. One that if you get it right makes every other process less important. Prioritisation. Good prioritisation is absolutely critical.

In most software projects there is either finite time, or finite money. If you are happy to take a reduced scope if one of those runs out, then the estimation process hasn’t really helped. ‘But we would have known how much we’ll get at the end up front’, you cry. Of course you wouldn’t have – you’ll have gotten a guess. You may get more features, you may get less. Exactly the same amount as if you hadn’t estimated.



Now, some people may tell me that if the estimation said they wouldn’t get everything in time, then they would just pressure the development team to work a whole lot more hours per week. Please note:- It is still going to take the same amount of actual working time- We really need to have a different chat…

I have some questions…


**How will know what to work on?**Whatever is top priority.

How will I plan my work? When you finish one thing, do the next highest priority thing.


**How will I know when we’ll be done?**You won’t. You never did. We’re just being honest about that now. Do frequent check-ins with your Stakeholders to show how far you have got. Use that to give them a better idea as you go along of what will and won’t be done, and make sure they constantly re-evaluate the prioritisation of items.

The discussion should always be about getting the most important things done, not the most things done.


**How can I hold my team accountable – I won’t know velocity!**Do you not trust your team? Do you think they’re slacking off, not working as hard as they could? Who created those estimates previously – if you can’t trust the team now, why did you trust their estimates?


**Is there really no value in estimation?**There can be a value in the conversations that things like story pointing sessions allow. When you have an inexperience team, they won’t know what things are complex (especially if you are working on a tangled legacy application) so will struggle to know how to break things down. If you have a large team, communication can be harder, so information sharing about your application or ecosystem takes longer and is more complicated. However there are other ways to have those conversations, and if your focus is ‘estimation’ it can be easy to lose sight of the fact that the conversation, and not the numbers on the stories, is the key piece.

How do you know you’re right? There is a lot more that can be said here, and I can only speak from my own experiences. There are obviously nuances not covered here. You may agree, you may not. Feel free to comment and let me know, or alternatively give me all the claps. Either way I’ll be playing snap with my planning poker cards while other teams are fighting over whether something is a 3 or a 5.

I hang out on twitter @virtualgill where this conversation started but didn’t fit into tweets.