Throughout my early career, I struggled with making estimations for technical work. With less than two years experience under my belt, I had no idea how long most tasks would take, because everything was new to me. That feeling lingered for some time. I never knew how to answer the questions I got from my project managers: "When will this be done?" "How many days do you think it will take?" "Is this something you can finish this sprint?" shrug

A few years later, craving growth and more responsibility, I took on the role of tech lead in my team; I was the accountable person for the delivery of a specific project. One of my duties was to make estimations on technical tasks. Initially, I was pretty uncomfortable with the process and even made some mistakes. Sometimes my estimations were wrong and things did take longer than I had originally projected. Most of the time, barring any major deadlines, this was not as big of a deal as I had feared. As I tech led more, with a new found perspective, I began to identify and understand patterns that I could lean on to make me a better estimator.

The skill of making estimations can differ a great deal depending on context. Sometimes you’re estimating at a technical specification level, which is more precise and specific. Other times, we’re estimating at a high level, such as defining Objectives & Key Results (OKRs).

OKRs & "Big" Estimations

When defining OKRs, our estimations are more an effort of prioritization. We have an overall goal (such as a goal to increase site traffic by X%). We have identified several streams of work related to meeting that goal. We look at past projects, headcount, and existing or competing workstreams to understand what can fit in a given period of time (often quarterly). We prioritize these goals to understand what must be done and what can slide.

Using past experiences

As we dig deeper into our identified workstreams, we can utilize that knowledge of past projects to understand where points of complexity might come into play. Whether we have to create a new component or integrate with new or existing APIs, our past experiences help us define the level of effort or how long it may take to complete the task.

Eliminate uncertainty

We should ask ourselves: of all the tasks we need to complete, what do we think will be the hardest thing to do? Whatever that is, do it first. Many times, it’s where our uncertainty comes from. If there is anything we are unsure of, we should work to answer open questions early on. Uncertainty can cause delays and large shuffles. We should try to eliminate as much uncertainty as possible.

Parallelize!

Next, consider tasks that include external stakeholders. We should aim to parallelize it. The team can then focus on priorities within our control while our stakeholders produce required dependencies.

Writing strong user stories

During this time, we are often working on the first draft of a tech spec. After that first draft, estimations get a little easier. We know more than we did before, after scoping our work and answering questions to unknowns. This is where the skill of writing strong user stories comes into play.

We want to have working software; we want to focus on delivering in tiers. We should be breaking our work down into atomic units, lending to milestones that bring value to our users. For instance, when working on a new feature on a non-existing page, we should first deliver the page itself as a milestone (even if it is initially barebones), then introduce the component integration later on.

Minimize context switching

This is helpful both for your team when working on delivery, as well as minimizing context for involved stakeholders. When there are too many variables in play or the scope is too large, we might make mistakes or overlook what might have been obvious in a smaller frame of reference. A good example of this in practice is during QA test sessions. We usually bring in folks from other teams to manually test our work before release. If there are too many variables to consider, a bug may be missed or it may be difficult to contextualize.

Breaking down work

Taking one step deeper, we may need to break down our work further and define how many days it may take for a task to be completed. That can be a little difficult to do. Even well planned and understood work can produce unknowns or difficult to answer questions. Rather than saying a task will take [x] number of days, we can look at it through a lens of relative complexity. If you know it will take one day to complete if you were doing the work, use that as a baseline. We can then point other tasks relative to that level of effort. If it is an unfamiliar task or work that sets a brand new precedence, inflate that complexity. Increase. Add a point for the things you don’t know. If new work comes into play, don’t blow the scope; add it to the backlog.

Enjoy the process

Ultimately, it comes back to writing good user stories. We don’t want to add all of the work to one ticket. Every logical component should have its own story, even if you’re working on it solo. When we learn something new, we can change our estimations. The tech spec leads us in a project and is a valuable process, but at the end of the day, our backlog is the source of truth. The process is the reward.

In the words of Nike, just do it

Making estimations is a tough, yet valuable skill. People get better at making estimations within the context of their team and their org by doing it. Use your memory. Remember what went well or what went wrong last time, and use it as a guideline for projects in the future.