December and January are when most companies focus on budgets, but you can be asked to estimate a project most any time of the year. And no matter what happens, managers are always measured against their budgets, so you want to get your estimations right. But when we don’t know exactly what the dev team will be doing, we’ll have to take some educated guesses that involve estimates. That’s why managers fan out across their teams to start asking questions that involve lots of hand-waving and very few requirements. I once had a conversation with my team that went something like this: Me: “We’re thinking we want to build the unified content module in 2014. Can we talk for 10 minutes about how big that is and what it might look like?” Team Member 1: “Do we have any actual requirements for it?” Me: “Nothing very specific. I think at this point we know …” The conversation went from there, as we discussed what we thought the unified content module was and what its overall architecture would probably look like. We then honed in on an estimate of about five man months for the work. Were we right? Probably not. Did I put it in my budget? Absolutely. For every time our estimate is way too high, there’s a time when our estimate is way too low. In the end, it should all work itself out over the course of the year. As an engineer working on a team, it’s useful to be able to do these kinds of rough estimates based on vague requirements. You’ll not only be a hero to your manager, but you’ll also get better at sizing projects at work and in your personal life.

Top-Down Versus Bottom-Up Estimation

Estimating a budget is a top-down process. Contrast this with the bottom-up estimation process most of us use. Doing a bottom-up estimation is simply taking all of the tasks involved in a project, estimating each of them and adding them up. This is really useful for smaller projects and for ones that are well understood. For example: Project: Add Phone Number to the User’s Profile. Tasks:

1. Add field to database (1 hour)
2. Add field to create /edit form (2 hours)
3. Write validation for forms (2 hours)
4. Add phone number to display in user list, admin user list, and user profile pages (1 hour)
5. Write tests (3 hours)

Total time: 9 hours Bottom up estimation, however, has one major weakness. When you don’t fully understand a project, it simply can’t be done. In that situation, top-down estimation is the way to go. It’s based on similar projects and past history. Rather than finding the parts of the project, you find similar projects and base your answer on that.

How to Create a Top-Down Estimate

To create a top-down estimate, you identify similar projects and consider what made them take as long as they did. Then combine the aspects of those past projects with what you know about this project to come up with an overall estimate. Here are the steps:

1. Identify four or five similar projects from prior experience.
2. Determine how long each project took in man months.
3. Identify the things that contributed most to each project’s duration.
4. Apply that learning to your project.

What’s a similar project? One that has characteristics like the project you’re estimating. You’re looking for projects that are:

• In the same or a similar architecture.
• Of about the same size (e.g., adding a field versus adding a module versus a whole new product).
• Started with about the same amount of information.

Determining how long the project took is usually a matter of asking the project manager. To get man months, simply multiply the number of months the project took by the number of people on the team. Don’t forget to include the time spent testing, bug fixing, integrating and incorporating feedback. Identifying what made the project take so long is the tricky part. Retrospectives or postmortems can be good sources of information. Otherwise, you’ll have to rely on the history in your ticketing system and commit messages. This is simply a list of influencers. There’s no need to put a specific time by each of them. Once you have all the influencers, duration and related projects, you can estimate the new effort. This should almost certainly be a conversation around the rest of the team, and involves comparing the new project to the old. The conversation usually goes something like this: “Well, project Next is like Project Past 1, because we had about the same amount of information going in, and we found a lot of architectural holes along the way.” “Yup, and Project Past 1 took eight  months. However, that one was adding a whole new product to our suite. This is just a module. A big module, but still just a module. We won’t have the whole overhead of build configuration and deployment.” “True. Project Past 2 was a new module, and it only took five months. It wasn’t as big an architectural extension, though.” “Yeah. So maybe somewhere between Project Past 1 and Project Past 2?” “Sounds about right. I’m scared of this bit about customers having direct access, though. It’s a module, sure, but it’s a huge module.” “Mmm. I’m not as worried about that, but it does seem like we’re going to have a few rounds with beta customers, so we should probably allow ourselves some time to do the user interface at least twice.” “Definitely. So maybe more like seven months than five months?” “Yeah, I could go for that. Seven months.” There’s your top-down estimate. It’s based on analogies rather than on breakdowns, but it still considers the history of the team, the product and the company. Therefore, it’s more of an educated guess than a completely made up figure. This kind of estimation based on very limited understanding goes under many names: SWAG, side-of-a-barn estimate, 50 percent estimate and others. The point isn’t to be precise or terribly accurate. Indeed, the name 50 percent comes from the idea that you’re probably up to 50 percent off on your estimate. The point of this estimate is to feed into another estimate. If you’re lucky, and if your manager is good at managing scope along the way, all of the fuzziness in requirements and understanding and estimates will come out about even. Then, you’ll hit your estimate with something that roughly fits the needs of the project. And that’s a budget win.