Did it take the predicted time?
If you came across this article in your Medium feed it will have provided you with an estimated read time. What is the value proposition of this estimate? It allows you to make an important decision about a really valuable thing, your time. The actual value is somewhat irrelevant as some of us (me) read much slower than others. However, it does allow all of us to gain an understand of the commitment and therefore make a decision. So thanks for spending however long it took you to read until this point.
In software-delivery estimates are often seen as a bit of bugbear*. It turns out that crafting software well is actually ridiculously complex. What can appear to be a simple product idea, often has to be viewed through many lenses such as:
- Who is the actual customer? What is there persona?
- What technology do they use and prefer?
- What level of security does this need around it?
- How scalable does this need to be?
- What is the technical capability of the team?
- Where is the technology in its lifecycle?
- If the customer likes this now what will they like by the time that they get this?
- What experience do we want our users to have?
- etc
The simple idea soon balloons in complexity. What’s more, every person on the team could have different views, ideas and perspectives based on their skills, experience, biases or just gut feelings. The point being when asked to create a product or a feature it’s often almost impossible to give an authoritative answer.
*Bugbear as in — a cause of obsessive fear, anxiety or irritation. Not the child eating hobgoblin that you defeat with a spell of magic arrow.
It’s a little like this. If I show you a picture of a bath, you would have a hard time telling me if its warm enough to get into. You would struggle to estimate the temperature even if you could see steam rising from the water. The only way to get a good understanding of the estimate is to experience it (I’m discounting the thermometer here). Dip in a toe and you’ll have a feeling for the estimate but if you want a really good one dive right in. Software is similar the further we get into it the better we understand it.
However, estimating the size or completion date of something at the outset has become the norm in the business world to the point that it’s often baked into the process. Annual budgets, quarterly reviews, performance appraisals and financial results all push us to determine what will be realised when. The system pushes us to predict the future.
This conflict between a desire to predict the future and our inability to do just that creates a lot of pushback on giving estimates, as they are invariably wrong.
So why am I writing an article on why estimates can be useful?
Firstly lets nail down when estimates are useful. Estimates are only useful when you can make a decision, off the back of them. If you can’t or won’t make a decision from your estimate then save yourself an awful lot of effort and don’t bother estimating. I’ll say it again.
Estimates are only useful when you can make a decision based on them.
As we saw at the top of the article the reading time of this article isn’t going to be correct but it does allow us to make a choice. If your estimate allows you to determine if you build feature X or feature Y then it has some value, give it a go. If estimating your project will never lead to any change, then why estimate it.
Which brings us onto when not to bother. Some efforts are obviously the right thing to do regardless of the estimate. It might take a decade or half a century to achieve carbon neutrality. Getting on with it is far more important than debating about how long it will take. Some things are just important and if so, just do them.
As outlined above being asked for an estimate does surface an awful lot of unknowns. When the estimates are attacked collaboratively it can allow a massive amount of shared understanding to be created. This allows the complexity of the actual request to become apparent, often shining a light on the associated risks and opportunities. Perhaps most powerfully it allows the team to come to a shared understanding of the problem to be solved. So if you are going to estimate do it collaboratively. If you don’t need to estimate get your teams together in a room and make sure that the problem and outcome are truly understood anyway.
So the simple guide to estimates is this:
- Only do them if the estimate is going to lead to a decision being made. Understanding why this decision is important is key.
- Make the time you spend on estimating relate to the importance of the decision that will be made. They’re likely to be wrong so understand the impact of that wrongness is important. I’ll put more effort into estimating the time it will take to get the station if someone is waiting for me than I would if I was off out for the day. That said, spend as little time as possible.
- Approach estimates collaboratively to gain as many benefits as possible from your efforts. This will produce positive results regardless of if you are being asked to estimate or not.
Some estimating hacks that may help you:
Heuristics is our friend when we want a quick estimate. Get everyone to give their gut feeling. It’s important to do this in a way where people don’t get anchored on each other's estimates. The figure will often be good enough.
Wisdom of the group, especially if that group is diverse and has a high level of psychological safety can give you better insight and therefore a less wrong estimate.
If you’ve done some of the work then let the math do the heavy lifting for you. You can easily calculate average through-put which will give you an answer quickly or you can get fancy with a Monte Carlo simulation. The estimate for this article is calculated automatically from the number of words. You can perhaps do the same with the number of backlog items.
I hope you’ve enjoyed my little exploration of the positives of estimation. If you did, let me know. If you didn’t, let me know.
About the author:
Chris Davey works at understanding people and how they interact with one another. This has caused him to explore life coaching, CBT, NLP and in a very large part himself. He spends his days helping people work together, often with-in the software industry. In his spare time, he likes to create, playing and writing about games (http://awaitingmaturity.blogspot.com/), snowboards, travels and now and again just sits and thinks. You can keep up with the adventures on www.steelcurve.com, Medium @chrisjsdavey, LinkedIn https://www.linkedin.com/in/chrisjsdavey/ , Twitter @Kemlock and www.steelcurve.com. If you are really determined you can catch me on most PC gaming platforms as “Chemlock” or “AwaitingMaturity”.
