Estimates and Assumptions
“Estimates” — that word makes engineers shudder. An estimate at the highest level is a way to say that a task will be done in an approximate amount of time. No one wants to be stuck in a position where they thought something would take a lot less effort than it actually did, thereby getting crunched, working weekends, getting yelled at by managers, etc. to deliver on time. No one wants that. That said, every business on earth needs to have some understanding of a timeline as to when milestones can be expected in order to plan how to operate. Damned if you do, damned if you don’t, as they say.
At Ashe (my former agency), my entire company’s profit margins were based on me being able to bid on client projects using accurate estimates of time, which would directly tie to the budget of the project. Anytime I was wrong about the scope I stood to lose money… and I never once lost money.
What causes an estimate to go wrong?
Think back on all those times something has been late or behind delivery. If I had to guess, I’d say no matter which example you are thinking of, there was one common, glaring factor: project entropy. Project entropy is the area of uncertainty where things, when not clearly defined, can cause expectations to differ wildly, and thus a high potential for extra work. Entropy only exists in that “undefined space” between everything else. So the good news is, if you can minimize entropy, you can also minimize the risk of a project going awry.
Think about a project where you had read a few happy path user stories. User buys a pair of shoes on the website. We define the scope of the project as “let the user create an account, add shoes to cart, checkout.” If we work from just that user story, then who makes the decision about users that cannot create accounts? What about users on other devices? Or how about if the particular pair of shoes have other necessary metadata, such as color or size that we are sold out of? Without defining all of these additional components, there’s no way to create even an approximate estimate.
How do you minimize entropy?
When you think of an estimate, there are two obvious components that you know you’ll have to help define: scope and timeline.
But if these two things are not aligned correctly, a massive potential for entropy exists. At least one of these is typically a fixed, unmovable variable: if the scope is too big, the project will need to take much longer. Conversely, if the timeline is too short, the scope will need to be reduced. On top of that, having to make these changes or pivots on the fly will add to the entropy of the project, thus potentially making it take even longer to deliver.
So how do we keep those two things from being able to swing so wildly? There is a very important but under appreciated aspect of estimating, and that is assumptions. Assumptions are hugely important to define for two reasons:
1. What am I assuming that could affect the scope? They communicate very clearly in the scope the areas where decisions have been pre-emptively made, even if they are not the correct ones. If those things need to change, so do the scope and timeline.
2. What are all of the assumptions that we have made? Most of the time people have different assumptions. It is hugely important to get those built into an estimate so that everyone can see that they share assumptions, and know that if there is something missing it should be contributed.
By applying these assumptions, you are filtering out all the parts of the scope that you are less confident in their level of complexity. This way, your scope is only what you believe with a higher degree of certainty is achievable — or what you believe has the least entropy.
Assumptions are used to focus the scope to a level of precision that an engineer should feel confident and comfortable with delivering that particular task or feature. I know that if I define the above task as “assuming the shoes are in stock, and assuming the customer has sufficient funds in their account, and assuming the user has an active email address”, then we can with a much higher degree of confidence describe the length of time it will take to accomplish that task.
Side note/another feature of clearly defining assumptions:
Calling out assumptions can be an extremely helpful feedback loop into the UX team. Typically, calling out assumptions will help identify certain cases of the user experience that still need to be defined. As developers, sometimes making too many UX decisions on the fly can add significant entropy.
How do I get better at estimating?
Estimates are a challenge for many developers, and that is okay! But how do you get better at providing estimates ahead of doing weeks of discovery work?
It is one of those things that you start out sort of “better at it than you think” and then with a little practice you can generally rely on your approximations to end up being pretty close to accurate. You can probably already do this pretty well now! That is part of the engineer mindset — we look at everything as a collection of systems, think about the individual components of those systems (maybe recurse down that chain a few times), and then aggregate all those things together to say “here is how I would solve that problem.” Even if you don’t do it consciously, you’re doing it. How many times have you hit an annoying UX thing in Jira and thought subconsciously “here’s exactly how I’d fix that”?
Estimations are just about breaking things down cleanly and clearly — what are the more complex systems to achieve this particular task? What are the more complex components of those systems? And how can I use these notions to create an accurate estimate? Be iterative!
What next? Start trying it!
Instead of fleshing out a full discovery document, start by thinking about the three parts of the estimate (and identifying which one of those is fixed). How much time can I spend on this task (timeline), what can I confidently do by then (scope), and what will I not have to worry about (assumptions)? Then you can iterate on that: what else can I add with a high degree of confidence if we change one of the assumptions? Over time, it will start to feel like these approximations are really close to what you actually determine after doing a full discovery, and you’ll feel way more confident in committing to your estimates with way less risk of entropy.
