Making accurate estimates in software development

In every software development project, we have to make estimates - how long will the project take? How much will it cost?

The truth is, though, that this is not something we’re taught in college, nor in our coding bootcamps, YouTube tutorials or Stack Overflow threads. And once we have to do it, we quickly realize the key thing about it: making accurate estimates is extremely hard.

Let me illustrate the point with a non-development example. Let’s say you’re buying food and drinks for a skiing trip with friends. This is the information you have about the trip:

• There will be 6 - 10 people.
• The trip will last 3 - 5 days.
• People have different food preferences - you need to be innovative and think outside the box.
• Buy some drinks, but not too many. And don’t forget about tea.
• Make sure to get the best possible quality for the lowest price.
• Before you go to the store, tell me the final bill and how much time you’ll be spending in the store.

Seems quite complicated, right? Well, software development projects, depending on their size, often have significantly more moving parts and changes down the road than a skiing trip.

In this blog post, I’ll go through the main reasons why making estimates is so difficult in software development and provide you with essential tips to help you make as accurate estimates as possible.

 

Why is making estimates so hard?

Front-end and back-end developers have different reasons for having trouble with making accurate estimates.

Front-end developers

• They only receive wireframes for the design.
• The designs look easy, but there are no descriptions of animations.
• They get no specifications for different devices and screen sizes.
• The client doesn't actually know what they want until they see it.
• The client assumes that something is easy to achieve if they’ve seen it on another site.

Back-end developers

• The task description isn’t detailed enough.
• You’re new to the project, so you’re either missing the big picture or not understanding the overall business logic.
• The project uses 3rd-party services you aren’t familiar with.
• The project uses a technology you aren’t that comfortable with.
• The project’s requirements change as it progresses (holds true for front-end developers as well).

Additionally, and this also holds true for both front- and back-end developers, we often have idealistic views of our own capabilities, which can pose problems when making estimates and in particular following our estimates.

Finally, another underlying reason for making inaccurate estimates has nothing to do with the project, your level of experience or the technologies used. It’s actually an essential human trait: a strong desire to please other people by telling them what they want to hear. 

When making estimates, this desire often translates into providing very optimistic estimates in terms of both time and budget, which more often than not don’t stand up to the test of scope changes, back and forths with the clients, and any other unexpected disruptions. 

 

Key tips for making estimates

So, with all this in mind, let me reiterate: making estimates is hard! Your best bet is to lean on past experience, but you of course won’t have this option when you’re new to software development and making estimates. 

Here are some essential tips for getting through these initial hurdles and having the right mindset for making better estimates, together with examples of tasks to illustrate this.

 

1. Break down the work

It’s much easier to estimate smaller activities than larger ones. By breaking down the work into smaller tasks, you’ll get a clearer picture of all the requirements. Consequently, your estimate will probably be higher (read: more accurate), plus you’ll likely figure out that you have additional questions.

Requirement: Build the front page

What you shouldn’t do: “Looks pretty straightforward, a day should be more than enough.” 8 hours.

What you should do: “Let’s break this into smaller pieces:

1. Create a “CTA” section with a slider and links. 4 hours.
2. Create a “Latest news” section with a list of news and a link to each piece of content. 2 hours.
3. Add a “Solutions” section which has an animation for each solution icon on hover, which will need an SVG animation. 8 hours.
4. Add a “Contact us” form at the bottom of the page. 4 hours.

Total: 18 hours.

As we can see, the estimate is totally different if we break down the task into smaller tasks and thus get a better understanding of all the requirements. 

 

2. Ask questions, don’t assume

Task descriptions that you’ll get will often be missing vital information. You might understand something differently than the client, and even if you are on the same page, certain things can be done in multiple ways. 

Assuming without asking questions would be almost like playing a version of the telephone game, where the final result is unlikely to reflect the client’s initial need.

Requirement: Each page needs to have a breadcrumb

What you shouldn’t do: “Oh, nice, this is an out-of-the-box feature of the CMS.” 2 hours.

What you should do: ask questions to get as much extra information as possible. Do we follow the menu? Is there a pattern for the breadcrumbs? If so, are there any special pages that won’t follow this pattern? If yes, which ones are they?

By asking questions and getting deeper into the problem, you’ll very likely produce a much higher estimate than by just assuming - but the work will be that much more likely to meet the client’s needs.

 

3. Propose adjusting the requirement

Maybe there’s an existing solution to the problem at hand, or it could even be a core feature of the technology you’re using. You can spend (or even waste) a lot of time working on a feature that you don’t feel is vital to the project.

By proposing to the client to adjust the requirement, it may open up the possibility for a better solution that even ends up being faster to build. If your solution ends up saving time and money, the client will definitely appreciate it.

Requirement: Every image upload has a mobile image upload (fall back to original if there’s no image uploaded for mobile)

What you shouldn’t do: “I’ll create two separate image upload fields, then write some logic for falling back to the desktop image if no mobile image is present. Should I just print both and hide one with CSS?” (This last one completely defeats the purpose, by the way.)

What you should do: ask the client if the reason for this is just the size of the image, or are they planning on uploading different visuals. Tell them about the responsive images feature your CMS might have, which makes use of the <picture> tag and allows you to upload once and select different styles for each breakpoint. It may turn out that this was exactly what the client wanted.

You may have noticed that point number two, asking questions, plays a major role here as well - you cannot propose changing a requirement if you don’t have a deep enough understanding of it. 

Changing a requirement doesn’t mean that the client won’t get the feature they want. On the contrary, it may lead to a solution that’s even better aligned with what they need.

 

4. Take your degree of confidence into account

Referring back to the reason for making inaccurate estimates that’s common to both front-end and back-end developers, you should take care not to overestimate your abilities or experience. 

Before making any estimates, ask yourself these questions:

• How familiar am I with the situation?
• Have I done something similar before or is it something totally new to me?
• Do I have all the necessary information to complete the task?
• Am I new to the project or have I worked on it before?

Requirement: We want our users to be able to log in with their Twitter account

What you shouldn’t do: “I just made a Google account login a month ago, it’s probably more or less the same.” 8 hours.

What you should do: “Ok, I’ve made a Google login, but I’ve never worked with a Twitter API. My degree of confidence is low, so I’ll take 8h as a base, then multiply that by at least 2. 16+ hours.

 

5. Use a sequence

Development teams usually agree on a particular sequence for their estimates, e.g. the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) or a Fibonacci-like sequence (0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100).

In agile software development, estimates are typically done with story points rather than actual hours. The two story point sequences most frequently used are 1, 2, 4, 8, 16 and 1, 2, 5, 10, 20.

It’s key for all developers working on the same sprint or project to stick with the selected sequence for all their tasks. For example, when you’re using the Fibonacci sequence and know that a task will take longer than 5 hours to complete, choose the next number in the sequence (in this case 8) rather than the next natural number (6).

 

6. Set a maximum number of hours per task

You (and your team) should set the highest limit for a single task. As we just saw, no task should take longer than 16 hours, or 20 in a Fibonacci-like sequence, for example. If it’s bigger, break it down into smaller parts, as we covered under point 1.

 

7. Don’t forget about the things we tend to forget about

Finally, we need to mention all the things besides the actual development that you’ll need to factor into your estimates - but which a lot of developers tend to forget about when making them:

• Communication, meetings
• Initial setup
• Revisions
• Testing
• Bug-fixing
• Deployment

These are all key and inevitable parts of any software development project you’ll be working on, so make sure to have this in mind during initial planning and estimating.

 

How we approach it at Agiledrop

Most of what I’ve discussed in this article is based on the way we’re used to doing things at Agiledrop. We’ve been following these guidelines ourselves and have really improved the accuracy of our estimations over time by doing so.

One thing we do that I believe has really contributed to this is the fact that several different developers often go through the estimates for the same task, which gives us an even better understanding of the task and its potential pain points, as well as helps us be even more accurate in the future.

 

Conclusion

So, to recap, these are the key things to do when making estimates in software development:

1. Break down the work into smaller tasks
2. Don’t assume without asking questions
3. Propose adjusting the requirement
4. Factor in your degree of confidence
5. Agree on a sequence for estimating
6. Set a maximum time limit for each task
7. Don’t forget about the extra things

I hope these tips will help you in all your development estimates. All of this may take a bit of time getting used to for those who are just getting started with client projects, but the more projects you do, the more intuitive it will all become, and soon you will start feeling much more confident in making accurate estimates.