The Green Coder [Issue #3] - Giving good estimates

This is an archive version of issue 1 of The Green Coder, a short experiment which has since morphed into The Fresh Engineer Podcast. Check it out for a continuation of these thoughts!

This week I was having a chat with Anna Beltrami, she's our amazing iOS developer and is quite new to our team. We were trying to figure out some estimates for a couple pieces of work, towards the end she asked a question which got me thinking.

I think I need to be a bit more realistic with my expectations, and become better at giving estimates. I am usually too optimistic and don't take surprises into account. Do you have any tips on how to become better at giving estimates?

There are two truths in the world of software.

1. Every day you're going to get asked when something will be done.
2. No one in our industry has any idea when they're going to have anything done.

Whether you're a junior engineer on day one or a senior engineering manager with a decade of experience, you're going to be asked for estimates nearly daily. So how can you give good estimates, especially when you're new to the job?

What does a good time estimate look like?

A good estimate sets a shared expectation between you and the person asking. It should act as a starting point for conversation, and should always come with context to ensure the asker walks away feeling well informed, even when your estimate is vague. Here are the key things you want to convey with a good estimate.

1. A time range, you'll rarely be able to estimate an exact date or time for something so give a time range. 1-3 working days, 6-8 weeks, 3-4 hours - whatever your estimate is, the moment you give someone a range they know it's not a deadline you're promising but an estimate.
2. An idea of the risks that might cause a delay. When someone asks for an estimate, they don't just want a date and time, they want to learn about the progress of the task. By listing out some risks or possible reasons for delays, you open up that conversation and allow them to ask more questions.
3. A confidence level in the estimate you're giving. If you're estimating 6-8 weeks for a whole project delivery, how confident are you that it'll be within that range? Is it using all new technologies and it's a "finger in the air" estimate, or maybe it's something you've done 1000 times but you're just waiting on another team to finish a dependant piece of work.

The person asking for the estimate wants to walk away more informed, they usually don't mind if you're unsure of your estimate - they just want to learn a bit more to help enable them to progress on something themselves. Here's how one of my recent estimates sounded:

It's a pretty big piece of work, my gut says about 6-8 weeks but we've not done much investigation yet. If it's similar to X that we did last month then it'll be closer to 6 weeks, however if we want to do user testing first then it could be longer than 8 weeks still. Assuming the spec we've got doesn't change too much, I feel fairly confident we'll deliver it within 6-8 weeks.

With this estimate I've given a clear time estimate the person, in this case a Product Manager, can lean on. I've also included a bit of information about the risks, in this case we haven't done user testing, and a way the risk might be avoided. I've then given a rough idea of how confident I am in the estimate given the current spec that we both have.

How can I improve my estimates?

The central part of a good estimate is considering what might cause a delay and how likely it is that those issues will happen. This is also the core of why many estimates are wrong, you can't know every potential problem no matter how experienced you get!

Try to list out between 3 and 5 possible things that could cause the task to take longer and try to figure out which of those is most likely.

If you feel like you're struggling to make accurate estimates, there are usually two possible reasons.

1. You're not considering enough risks around a piece of work. If you think this might be the case, I would suggest taking your time over estimates, try to list out between 3 and 5 possible things that could cause the task to take longer and try to figure out which of those is most likely. For those, you'll want to add an appropriate amount of extra time onto your estimate.
2. You're working with a lot of unknowns that you are struggling to identify. This will definetely be a problem when you're in a new company, or a new job role. If you are new and this feels like it might be part of the issue, it's okay to add extra time into your estimates to account for it. You can even highlight it as a risk! It's entirely valid to say "I've never done this before so it might take me a few days more than someone else".

When you're in a new job or tackling something new, it's okay to take longer over estimates. It's quite rare that you'll be in a disaster situation and will be asked to provide an estimate for something, it's okay to ask to get back to someone, it's also okay to speak to others to get their opinions on an estimate.

Every estimate you give is an opportunity to exchange information, and build rapport with the person asking. Take time over your estimates, don't hesitate to make people aware of estimates which you're unsure about, and failing all else it's okay to say "I really can't begin to estimate that, I would need answers to X, Y, and Z first".