The Art of Estimation in Software Engineering

What do you do when you are trying to get a professional to do a home improvement project for you? Would you just speak to one trades person and then ask when they can start and hope that you can afford the job?

Or would you get a few quotes from different tradespeople and then compare them to see which one is the best fit for your budget and timeline?

I would think that most people would do the latter. Because that’s the most sensible thing to do.

You are analysing what’s a fair price and duration that it takes to get something done. You don’t want to over pay, you don’t want the project taking too long. So you do your due diligence.

You then get the information that helps you make trade-offs and make a decision that is best for you.

Maybe the people offering the best price for the job, isn’t available until much later. So you could decide to go with the slightly more expensive option to get it done sooner, simply because of availability. That works well if getting it done as soon as possible is the primary concern.

All that sounds great and sensible. Yet, I have observed that many engineers in the software profession, dislike estimation.

Why do software engineers dislike estimation?

Although estimates are a prediction, quite often, some organisations treat them as facts or actuals and commitments that the team is making.

In software development, when your organisation wants to move fast and accomplish magical results, there isn’t enough time to assess every minutia of detail! One has to do some mental gymnastics to account for complexities and come up with a story point or t-shirt size or in certain scenarios, the exact number of months or weeks. And once this information is shared, the organisation or your boss, treats your word as a pact and holds you accountable for it! Even if the tiniest of things go wrong, you end up suffering the consequences in your performance reviews!

At this point, I hope you find a better place to work.

That’s exactly why engineers worry about giving estimates.

How to approach estimation effectively in software engineering

It all starts with understanding why you are being asked for an estimate. What does it help with? Why does my manager or product manager or head of engineer need to know this?

I touched upon some of this in the introduction part of this post.

As a software engineer or engineering leader in any stage of your management career, estimates of a project help assess the opportunity cost. It feeds the decision tree and help us compare the trade-offs of different options.

With additional context, it helps us make a decision that is best for the organisation and the team at that particular time.

For both the organisation and the team, it helps the stakeholders understand if they are over-committing or under-committing.

Estimating the effort required helps us also plan for capacity - how many engineers might we need for this very large project considering all the other things we have committed to with the team we have today. How much could we parallelly execute, by when should we get the teams setup and ready so that we can deliver the project by a certain date? So many questions that need signals to be answered. And estimates help give us that signal.

Nobody can predict the future and most often, nobody expects you to, unless you proclaim yourself to be an astrologer. Then you are on your own.

In the software engineering context, our past experience feeds meaningful insights into the breakdown of a project. This is what we need when we provide or seek estimates. It is a signal - a signal to the stakeholders that tell them that those giving the estimates have thought about the problem in reasonable detail to have the confidence of a certain level to provide an estimate of the effort required to complete the work. And quite often, the estimates are accompanied by assumptions and risks to make the constraints and boundaries of the estimate clearer.

Estimating large ambiguous projects

As a junior engineer or someone starting your career in software engineering, this might be a ridiculous thing to take on. You probably have no data or experience to make a reasonable estimate for even small projects, so large ambiguous ones are out of question. I would expect someone like that to rely on the wisdom of someone with the experience to provide the estimates.

Now for a mid-senior level engineer, you might have some experience and data to estimate with reasonable degree of confidence. This again depends on the breadth and depth of your experience.

• The breadth gives you a wider perspective of factors that impact estimation
• the depth gives you the ability to drill down into the details to provide an estimate with a higher degree of confidence.

The more experienced you are, the more comfortable you get working with abstractions in your head. This, in turn, allows you to make reasonable estimates with higher confidence even when there is lots of ambiguity. Is it going to be 100% accurate? No and nobody said so.

The general rule of thumb is that the larger the project the worse your estimate’s accuracy and hence the more margin of error you should allow for.

Don’t get me wrong, more experience does help. It is incredibly difficult to accurately estimate large ambiguous projects simply because there are too many unknowns and too many factors that impact the size of the work. However, whatever it is, the important aspect is communicating those risks, assumptions and dependencies to the stakeholders while you share your estimate.

Steps to improve the quality of estimates for ambiguous projects

A good framework that I use to estimate large initiatives or actually any work is by laying out the following factors that impact the size of the work.

• What is in scope? - the obvious question everyone asks - what needs to be delivered?
• What is out of scope? - this is just as important as what is in scope. makes the boundaries clearer.
• What are the dependencies? - other teams, external vendors, etc.
• What are the risks and uncertainties? - any obvious risks that could cause us to fail or delay the delivery of this project? What are we aware of - highlight them
• What are the assumptions? are you making assumptions when estimating this work? highlight those assumptions and the risks imposed by them in the earlier point
• When do we need to deliver this by? - this is crucial to help you work backwards and negotiate the scope of the work. Key to think about how you could slice the work and deliver the functionality iteratively.

I am a very visual thinker. I like a board - black or white or virtual. I like post-its or stickies (as some people call it). At work, I use Miro and create a board, with these sections for an initiative and then discuss all these factors, as a team or with the tech leads or senior engineers from my team or perhaps a cross-functional team. Once everyone is clear on those factors, we then shout how big we think it is, along with the confidence level we have in our estimate. Then we discuss the reasons behind our own estimates. This helps bring out the different perspectives and helps us arrive at a consensus on the estimate.

This has helped us repeatedly come up with estimates that we felt were more accurate than we ever could have given individually.

When done with engineers, product managers, QA and engineering managers in the same session, this can highlight gaps and open the floor to perspectives that you would never have thought of if it was only done by engineers.

All you have to do is create a miro board for the team, per quarter or for the year, and create individual frames per initiative or project. And in each frame, you create sections for the factors mentioned above. And open the floor to discussion.

Estimating smaller chunks of work - epics of initiatives

Generally as an initiative is broken down, the larger pieces of the work to get it done become epics. The lower you go in the hierarchy of work, the more details are revealed.

Once an initiative is estimated at a high level of abstraction, you ask your engineers to divide and conquer the work further into epics. So they scope the work in more detail and come back with what they think would be involved in getting those blocks of work done.

In essence, they will have covered the same factors as discussed earlier, but at a more granular level, perhaps not even realising they did cover those aspects. Then in the team refinement or backlog grooming sessions, whatever you choose to call it, you discuss the estimates and arrive at a consensus on the estimates for the epics or their child tasks/stories.

What about the units?

Excellent question. This depends on the size of the work and planning method that the organisation uses and the context too.

T-shirt sizes and time periods

Large initiatives that are cross functional work, are better sized in t-shirt sizes, so long as the t-shirt sizes map to a range of time - S - 1-2 engineering weeks, M - 2-4 weeks, and so on. Everyone involved in the estimation session, should be aware of this mapping to arrive at a consensus. This isn’t just weeks as in time elapsed. This is engineer-weeks. If an engineer were to work on the initiative full time, how many weeks would it take them to complete the work? That’s the question it is trying to answer.

Now naive engineers or engineering leader might take this as 1 engineer can do it in 1 week, surely 2 engineer can then do this in half a week!

Story points

This is a fantastic abstraction to estimate smaller pieces of work. And if you follow scrum, or work in an organisation that claims to be Agile, then you probably already are using story points. This fibonacci sequence abstracts the effort and complexity of the work into a nice little number that you have to often round up. This makes sizing work, relative to one another. It makes it easier to compare and reason about the work too. Helps you talk about how fast you are delivering - your velocity and how much you can commit to in a sprint etc. But it is not a great tool for large initiatives.

Engineering hours

This is too granular. I don’t recommend this level of estimation. I doubt you’ll have the luxury of time to delve into this level of detail. At this level, it is easy to get lost in the weeds. It also starts to make your team of engineers nervous. They will start to feel like they are being micro managed. So I would avoid this level of estimation. If you think there is a performance concern of some sort, I’d recommend you do the engineering week estimates and translate that into engineering-days and hours.

Always remember, an engineering day is not 8 hours of work. Productive engineering hours in a day is often less than 5. So keep all that in mind when doing your calculations to this level of detail.

Engineering weeks

As discussed in the first unit of t-shirt sizes, engineering weeks is a great unit to estimate larger initiatives and helps create your Gantt charts and timelines to help visualise your roadmap and delivery in general. But just as I said earlier, ensure that you are clear on what it means - an engineering week is 5 engineering days, each day comprising of 5 productive engineering hours or less - never more.

Resources

I will share tools I use:

• Miro frame example for running estimation sessions
• Spreadsheet template for capacity planning and estimations

Hopefully, your estimation sessions will be more productive going forward.