Thiago Carvalho

Posted on Apr 12

Estimating Software Projects

#softwareengineering #estimation #planning

Good estimates aren't just about predicting the future. They are mostly about making decisions with limited information.

Estimating a project can be a big challenge. An estimate is nothing more than a guess about the amount of time it will take to do something. Still, bad estimates can waste a lot of time. In this blog post, I'll share ideas and techniques that can help you create good estimates, not because they are precise but because good estimations lead to good decisions.

We'll discuss how defining a clear goal before estimating helps you spend the right amount of effort estimating, how Fermi estimates can help you estimate complex questions, the benefits of breaking tasks into smaller parts, and the importance of communicating assumptions.

Start with clear goals

First, define success in the context of the project.

Estimating a project with a clear goal is hard. Estimating a project with an unclear goal is almost impossible. Vague definitions of success can lead to conversations where there is the illusion of alignment. People are talking about the same project, but each understands the goal differently.

Vague definitions:

Complete the Checkout Redesign
Launch Checkout 2.0

Clear definitions:

Reduce the time users spend on the checkout from ~4 min to ~2 min by releasing a simpler checkout process that maintains or increases conversion rates.
Implement new payment standard X before the regulatory deadline Y.

Second, define success in the context of the estimation.

You could be estimating a project to:

decide if you should prioritize project A or project B
understand if you need to ask for additional help
make sure this change is released before a central bank deadline
decide if you continue with the project given how much it will cost
confirm that you'll need to ask for additional time or budget
check if you have enough tickets for this Sprint

The maximum amount of time you spend estimating and the precision of your estimates should depend on what you are estimating. The stakes of not completing a few extra tickets added to the Sprint are low compared to missing a regulatory deadline. Make sure you are not treating every estimation exercise exactly the same. Adapt your efforts to the context of what you are doing.

There isn't a precise formula to define how much time and effort you should spend on each type of estimation. It depends on your context, but here are a few questions that can help you think about it:

If my estimation is wrong, what's the worst that could happen?
Based on the information I currently have, is my estimate reasonable?
Once I have this estimation, how will it help me achieve the project's goals?

Use Fermi estimates

It is easy to become overwhelmed by data gaps when trying to get a perfect estimate.

Often, the best way to get to a precise estimation is to start with an imprecise one. In some cases, you'll notice that the imprecise estimate is good enough and save the time you would have spent getting to a precise estimate.

The Fermi estimate is a great tool for getting a first estimate.

This video has a visual explanation of this estimation technique.

The classic Fermi estimate problem is "How many piano tuners are there in Chicago?"

Before starting, note that you won't work with precise numbers. You'll work with order-of-magnitude estimates.

Order-of-magnitude may seem complicated, but the idea is fairly simple. For example:

100 is one order of magnitude larger than 10
1000 is one order of magnitude smaller than 10000

It is common to represent these orders of magnitude as powers of 10. The examples above would look like this:

10² is one order of magnitude larger than 10¹
10³ is one order of magnitude smaller than 10⁴

First, estimate the number of people living in Chicago. Note that you don't need to be sure if the number is closer to 1 million or 5 million people. Chicago is a fairly large city, so the answer is likely in the millions, or 1000000, or 10⁶.

Estimation:

Population of Chicago: 10⁶

Next, estimate how many people in Chicago have pianos. If we consider that 1 in every 100 people has a piano, we can divide our estimated population by 100 to get the number of pianos in Chicago: 1000000/100 = 10000 or 10^6 / 10^2 = 10^4.

Estimations:

Population of Chicago: 10⁶
Pianos in Chicago: 10⁴

Now, how many pianos are tuned in Chicago per year? 10, 100, or 1000? 10 seems too little. 1000 would mean tuning something like 3 pianos a day, which seems excessive. 100 seems to be a reasonable estimate.

Estimations:

Population of Chicago: 10⁶
Pianos in Chicago: 10⁴
Pianos tuned in Chicago per year: 10²

Now you can divide the number of pianos by the number of pianos tuned in one year to get an estimate of the number of tuners in the city pianos / pianos-tuned = piano-tuners or 10^4 / 10^2 = 10^2

Estimations:

Population of Chicago: 10⁶
Pianos in Chicago: 10⁴
Pianos tuned in Chicago per year: 10²
Piano tuners in Chicago: 10²

Following these steps, you estimated that there are roughly 100 piano tuners in Chicago. According to Michael Mitchell's video, there are 81 piano tuners in Chicago, which is not a bad estimate.

Fermi estimates generally work because your overestimates and underestimates tend to cancel each other out. Fermi estimates are not perfect, but they tend to give results within an order of magnitude of the right answer.

If something is hard to estimate, break it into smaller parts

If you are having a hard time estimating a particular task, try breaking it down into smaller parts and estimating each part separately.

For example, how long does it take to develop and publish an iOS weather app? It is pretty hard to estimate, so let's try breaking it down into smaller parts:

Get an Apple developer account
Learn some Swift
Design screens
Find a weather API
Integrate weather API
Submit the app for approval

These smaller parts may not be comprehensive, but they are more concrete than the original question and easier to estimate.

You can continue this process recursively until you reach a level of detail you are comfortable estimating.

Document and communicate assumptions

"Fixed targets struggle in a dynamic world" - Bjarte Bogsnes

It is unusual to start a project with all the information and resources you need, especially when innovating. When you communicate your estimate to your stakeholders, it is helpful to provide context for any assumptions.

Imagine that you are estimating a project where:

Your project estimation assumes another team will deliver an important API next month.
Your team does not have experience with C#, so you estimated the development time considering work you've done in another language plus some time for learning C#.

If you don't share these assumptions with your stakeholders, it may give them an incorrect impression of the level of certainty in your estimate. Sharing these early creates more realistic expectations and simplifies future conversations (for example, if the other team delays the delivery of the API).

It is okay not to know everything and to make assumptions. Just make sure you communicate with them.

Summary

Have a clear goal to avoid the illusion of alignment (where each person understands the project goal differently).
Fermi estimates are a helpful tool, you can use powers of 10 to arrive at good rough estimates without using precise numbers.
Break tasks into smaller parts.
Communicating assumptions.