I am a 10x developer. x is my original estimation.
"Wait, doesn't that just mean you are a normal developer?"
Possibly.
Most of us are notoriously bad at estimating time frames. This is especially prevalent when the task is large.
Let's say you had to estimate how long it would take you to make a single sandwich. Not too difficult, right?
How about making 100 sandwiches? You can just multiply your single sandwich estimation by 100, right?
That seems pretty logical but we may be disregarding some important factors. We will also need to account for the time it takes us to open numerous packages of ingredients. How about the time we use when moving between sandwiches?
These are cases that we usually do not deal with when making a single sandwich.
Per this example, we can see how our estimations can become inaccurate as we increase the scale of a task.
Estimating becomes even more difficult, or even impossible, when it comes to tasks we have not done before.
How can you estimate something that you do not even know about? We do not know what we do not know.
This is applicable to software development when we are tasked with implementing completely new features. Sure, sometimes, we may have an idea of how long it would take based on previous experiences. However, there are times when we have no frame of reference.
When we do not have enough information, estimations become counterproductive. Providing an estimate that may be wildly incorrect is stressful for the provider and frustrating for the recipient.
One way to combat estimation is to divide and conquer. Split the project or task into smaller sub-tasks that can be more easily scoped. As we saw in the sandwich example, we are able to more accurately predict time frames when the scale is smaller.
In software development, this would correspond to dividing up feature development into even smaller features. This will allow us to have a better estimations and iterate more quickly.
I believe that anything requiring a day or more of work deservers an attempt at being split up. I have consistently found that my estimations for work that extends across a work day are inaccurate.
Furthermore, here are some more benefits of divvying up larger projects:
Okay, great. But how can we estimate portions of a project that we have not experienced before? Where would we even begin?
Well, first off, we might have a better understanding of the scope if we break down the project. We might even be able to estimate the individual features even if we could not provide a good estimate for the project.
If we still can not provide a somewhat accurate estimation after breaking down the project, this may be a good time to introduce research timeboxing.
This is where we allocate a certain amount of time to research the feature to have a better understanding of its scope. Afterwards, we should be able to provide a better estimation than before.
Estimation may be an easy concept to understand but carrying it out is difficult. This is especially true in software development where we need to provide estimations for projects in which we have limited visibility on the actual implementation.
When in such situations, we can try to break the project down into smaller features where we may be able to better understand the scope and time frame. We may also need to deploy some sort of research phase to better determine the time requirement.
Hopefully, with these methods, we can both lessen the stress the estimator experiences and improve the deadline accuracy for stakeholders and users.