Estimates (Part One): How to Get a Good Estimate
For our first real blog post, we wanted to tackle a question that a lot of our new clients ask: “How do I get a good estimate from my developers?”
It’s a common problem. You’ve got a new project in the works, you might know what functionality you need, but you definitely don’t know how long it’s going to take. And while there’s no magic formula to be right in every estimate, we’ve found the following tips to be useful.
A Developer or an Estimator?
First off, it’s important to point out that some of the best developers aren’t the best estimators, and vice versa. Why is that? We believe it’s because estimating and coding are two very different mental processes. (Granted, this is only our opinion, but in our thirteen years managing developers at our sister company, we’ve come up a few theories.)
Coding is a task-based process – a coder works their way down a list of tasks to be accomplished. With a good tech spec in front of them, a coder probably doesn’t need to think that far outside the box and can most likely give you a good estimate. However, without a good tech spec, a developer has to rely on a more theoretical understanding of the project, which often leads to less accurate estimates. Estimation is a big picture process. To give a good estimate, a developer needs to think about all the additional scenarios past the obvious ones that might factor into the development timeline; essentially, everything that could go wrong and anything that might prove tricky or generate more discussion. And because being a successful programmer doesn’t always require that level of insight, coders often struggle to give good estimates without a clearly defined tech spec.
Something else to note: a lot of the time, when a client says they want an estimate, they actually want a plan. We’ll talk more in Part Two about the difference between an estimate and a plan, but make sure to think about whether you need one or both of those things when you’re asking a developer for an estimate. (Spoiler alert: it’s an important distinction.)
Getting a Better Estimate
You would never (and should never) get a high-level estimate, hand a project to a developer, and then not check in with them until they tell you it’s finished (unless it’s something really small). In order to get more accurate estimates (and more accurate coding) we rely on a mantra of “Trust, But Verify.”
Trust, But Verify works like this: You give your team tasks to complete, trust them to complete the tasks, and then verify that the tasks have been done correctly. This method allows you to (1) check in with your team frequently, (2) learn the strengths and weaknesses of your team members, and (3) catch any problems early, before they become big issues.
These are the steps we take when we put Trust, But Verify into action:
- Ask for a high-level estimate for the whole project. Get the big picture. It’ll give you a sense of whether you and your developer are in the same ballpark or on different planets about features and overall size of the project.
- Get a more detailed estimate for a small measurable task. We recommend something that will take 1-2 days of work (or 8-12 hours). That’s enough time to give you a good sample size of work, but also short enough that the developer should be able to do it without further direction (or further strain on your wallet).
- Do the work. Let the coder rock! Try not to bother them too much or ask for too many updates before your deadline. Programmers get in the zone when they code and you don’t want to mess up their mojo.
- Check the estimate against the work that was done. The coder estimated 10 hours and it actually took 9? Awesome! But if it took 18? Uh oh. Either way you’ve learned something valuable moving forward.
- Increase the length of the tasks until their estimating fails and figure out why it failed. This will give you a sense of the programmer’s limits.
As you work with your developer, you’ll get to know their individual strengths and weaknesses at the same time as you clarify the scope of your project and check its quality. It’s a win-win-win!
Follow these steps and you’ll be on your way to getting more accurate estimates from your new Rockstar Coder! Just don’t ask us how long it’s going to take to write Part Two. (Spoiler alert: Check back in a month.)