6 minutes
Estimations and Guesstimations
From a business and developer perspective bringing up the topic of estimations can elicit a variety of responses, ranging from mostly negative to frustration and apathy. Most devs would prefer to answer the question “How long would it take to do this?” with “How long is a piece of string?”. While this is probably an accurate answer it’s obviously not helpful in the broader scheme of things. So here I’d like to offer up some thoughts I have around this, some challenges I perceive and some possible solutions. Let’s dive into this “fascinating” subject! (I mean, it’s not shiny like AI or Rust, but bear with me, this is important!)
The Developer’s Perspective
Another industry that is notoriously bad at estimations is the construction industry, so I’ll use this as a (limited) example.
Imagine for a second you are an individual tradesmen, and you are tasked with building a house from scratch. Depending on your experience you might have some ideas of where to start and perhaps even the different steps required along the way. You could probably even guess how long certain sections of the build will take as they relate to your own specialisation and drawing from previous times you’ve done this.
Now take into account that while every building has similar sections, a foundation, walls, windows, a roof, etc. These can differ wildly depending on a myriad of factors and requirements. You might know how to lay a foundation for a two-storey house, but this would differ from what’s required for a 120-storey skyscraper. The inverse is also true, if you are used to building skyscrapers, you would probably over-estimate on what is required for a two-storey house. Yes, it would be super rock solid, but probably overengineered and dare I say, a waste of time and effort.
You also have no idea of the quality of the ground you’ll be building on - is it sandy or pure granite? How deep does the sandy part even go?
The project is on a tight deadline and doesn’t allow for time to go and measure the ground quality/depth in detail. The best you can do is fall back on previous experience, which might not fit this specific use case (Skyscraper vs. house). A lot of frustration, dashed hopes and probably broken things lie ahead here. Insert sad face…
The Business’ Perspective
As the business funding the construction of a new housing development you are on a deadline to finish as many houses as possible before funding runs out. You need to get people into these houses asap!
To accomplish this you need decent estimations on how long each house would take and how many people in total it would require to work efficiently. You need to know when, how much and when certain raw materials need to be ordered and delivered.
Most of these questions you would need to have answered up front, but you’d also need a view of the current situation in order to adjust accordingly. Project management is not just a buzzword after all!
The Problems
Fundamentally (no pun intended), there is a misalignment between the business and the tradesman’s requirements, compounded by time sensitivity. The tradesman lacks the information to accurately determine his own requirements and blockers, while the business is focused on time and financial costs.
To bring this example into the Tech world, we sit with the same conflict of perspectives and interests. A developer or team of developers need concrete (ha! More construction puns!) answers and information to accurately estimate and report these to the business so that it can factor it in. The business needs this information to manage expectations from customers, investors, etc. Taking into account some limitations around funding and time available.
Possible Solutions
I’d like to propose a few things I’ve seen so far that helped mitigate and bring these two perspectives more in line with each other.
Firstly, treat investigation and setting up estimations as a task in and of itself. Include them in the initial estimation, leaving room for the estimation to be adjusted afterwards. At this point it’s really a guesstimate, unless the estimate is purely for the initial investigation (Or “spike” if we’re speaking Agile). Treat this spike with extreme importance, dive deep and involve developers and stakeholders as early as possible. Identify blockers, unknowns and possible changes to scope. Communication is key, manage expectations all around.
Secondly, make sure the developer(s) are aware of the limitations the business is facing. This will help them suggest possible changes to scope and communicate issues earlier or even up front. The business should then take this feedback seriously and consider how this affects its objectives and how much room there is for changes. Communicate and negotiate as far as possible.
Getting down to the actual estimations, hopefully the initial investigation has revealed as much as possible, allowed an implementation plan to be developed and this has been communicated and agreed upon by all involved.
In regard to further estimations I find that the further in the future or the lifetime of a project they are, the more inaccuracy creeps in. What I propose here is to use the concept of milestones (or maybe alpha releases?). This would allow for estimations to be done on a granular level up to the first milestone. The milestone itself doesn’t have to be anything particularly functional, but it is a point to stop, reflect, consider the path forward, communicate and adjust if needed. Even iterate on the previous work.
Final Thoughts
A note on estimation points (or story points if you prefer). All companies and teams have different definitions of these. Some equate it to time, some to effort/difficulty and some a mishmash of both. I think I’ve encountered some if not all permutations around this so here are my thoughts on this and other points mentioned further up.
- Honestly, use whatever estimation metric makes sense for all involved.
- Everyone must understand that these numbers represent estimates, and therefore they are subject to change. But they should be accurate enough for the business to use them in higher level planning. Try to keep this balance in mind while estimating.
- I can’t stress how important it is that everyone agrees on what the units of an estimation represents.
- Stories that have a large amount of points/time assigned are red flags. While perhaps not always possible, one should strive for fairly straightforward tasks with low to medium estimations. Bigger tasks should either be broken up or have a targeted investigation first to do so. (Consider epics if doing agile)
- The person that will be doing the work should do the estimation.
- If issues arise during execution, communicate them early.
- If possible, rely on previous estimations of similar tasks/projects.
- Reach out to peers if you as a developer are spinning wheels/failing to see the forest from the trees. Different perspectives are super valuable.
No solution is going to be perfect, but I find some of these approaches tries to balance the requirements of both the developers and the business. Minimising frustration all around and making sure everyone communicates and reaches their eventual project goal successfully.
High five! We made it through! Maybe I’ll write my next post on how to train an AI using a million Raspberry Pi’s or something. We’ll see.