Yes, Virginia, You Can Estimate That
When and How to Estimate Software Projects
My very first time as a tech lead I ran a project to turn a single-node system into a distributed system. As part of running that project, my boss sat me down and walked me through the process of estimating the work and making a project plan. This estimation process was one of the hardest experiences of my early tech career. It is burned into my memory as a series of frustrating and tedious steps where I had to overcome uncertainty and the fear of making mistakes and missing pieces in order to create a plan that would pass muster.
However, the effort paid off, and the project ultimately delivered within 20% of the estimate despite huge unknowns (it was a brand-new bespoke distributed system, after all!). The tedious work of the estimation and creating a plan let us set goals for ourselves, kept the project from turning into a drawn-out, never-ending process — and no, it wasn’t a death march either.
I have since realized that few people have the benefit of having a great manager sit them down and walk them through the process of estimation, so I am going to share a few tips and tricks with you here. Let me start by managing your expectations on what success looks like. Successful estimation is an estimate that ends up being accurate within about 20% of the goal. You aimed for 10 weeks, did it within 12. You aimed for 8 features, ended up shipping 7. This process is not about achieving perfection but rather trying to bound the scope of failure.
Two Kinds of Estimation Exercises
There are really two kinds of estimation exercises in software:
- I know what I need to deliver, when do I think we’ll be done?
- I know when we need to be done, what do I think we can deliver by then?
Fortunately, most of the rules around estimation apply equally to both of these types of projects.
When to Estimate: Project Size, Duration, and Team
The best chance you have for doing accurate estimation is for something that is bigger than a small task, encompasses a team of people, and has a long timeline.
Small tasks are hard to estimate because you can be wildly off as a fraction of the total even though the amount of mis-estimated time is low. A task you believe will take you 1 day that takes you 2 days is a big miss, even though really it’s just a single day. Bigger projects are easier to estimate because you have more wiggle room. When you have something that you know will already take a long time to do it is common that you find places to make up any misses, and that the long duration actually doesn’t expand by a significant amount. Like I said above, a good goal is to be within 20% of the total estimated time.
Long timelines have the additional benefit of giving you time to justify planning. Planning takes time, and it is hard to justify planning time for a short task. However, for a very long task, the time spent planning, though it might feel uncomfortably long (more on that later) tends to pay for itself in risk reduction to the overall timeline.
A single person project has a lot more risk than a single team project. Team members can pick up slack for one another, help each other solve problems more quickly, and assign work based on the different strengths and interests of the individuals.
Multi-team projects, on the other hand, are extremely hard to estimate accurately, because of coordination and communication overhead that gets significantly more complex as you add more teams. Integration points are huge wildcards when it comes to estimation.
So, estimation works well for long projects that will be worked on mostly by a single team. This includes the parts of a multi-team project that are fully owned by a single team.
How to Estimate: Understanding Scope and Requirements
You can’t estimate something with an unknown scope and unknown requirements. The best estimates for software projects come from scope that is fully comprehendible by 1–2 people, where those estimators can gather up and articulate the mid-to-large tasks that will make up the project work.
Project estimation is no fun because you’re probably not writing code. The estimation process is more about reading code and gathering information than it is about writing code. 1–2 people can gather a lot of information about an existing system and accurately create estimates based on their understanding of the scope. Unfortunately, that means that you are taking people who probably prefer to write code and asking them to read code, talk to people, and think about tedious details instead of writing code.
Why not just estimate via coding? Well, to actually write code, we usually need to be deep into a set of details, and estimation is much less about details than it is about identifying larger risks and major unknowns. Trying to estimate via coding is usually a distraction and tells you less than you think it should. The desire to write code to make an estimate is often a sign that you are either not ready to estimate (still need to do research on a major unknown) or you’re avoiding the estimation in favor of something that is more fun and easy for you to do. As my friend Scott pointed out, software estimation actually includes a lot of software architecture and design, which helps us create better systems than taking prototypes and shoving them into production.
A good manager should be able to walk you through this process, as my manager did for me. It starts by sitting down and breaking up the project into as many parts as you can think of. For example, the very first step of a checkout system rewrite may be this list:
- create a new service
- map out the existing data model
- write out all the possible user actions
- rewrite the logic in the new system
- make sure the new system does the same thing as the old system
- rewrite the interface to call the new system
Some of these pieces are pretty clear and could be started on right now. Some of them are very unclear. There’s pieces that are completely missing, and not enough detail overall. Depending on the urgency, you may have someone start on the clear pieces now, but that person should not be you the estimator, because you need to go back to the parts of the project that are missing details and start to fill in those gaps.
After a few iterations of digging into details and gathering feedback you end up with a set of clearer knowns and unknowns. You can see the high-risk work to pull forward, you can see the places where multiple people can contribute and the places that may depend on a single person. You can see the external dependencies that can completely change the timeline (such as getting building permits approved, getting servers racked, or getting final design sign-off), and thus highlight those risks.
You will probably need to do a second pass towards the end, where you look at details of production readiness, quality, etc., that you overlooked in this early planning process. You may hit complete unknowns that require major adjustments to parts of the plan. But this up-front work will make the overall process far more efficient than it otherwise would have been by organizing the tasks and helping manage expectations of what the scope of the work entails.
The unknowns are greater in brand-new work, and it can seem even more impossible to estimate because of this. However, we often put brand-new features within existing systems. If we know the requirements, and have any existing structure to work in, estimation can be done so long as what we are attempting to do is not so far into the realm of “never been done before” that there are significant known unknowns.
The bigger challenge with estimating new work within existing systems is that our requirements change from under us. There’s no point in estimating something that is truly unstable in its requirements. Better to treat that as an experimental build, and build throwaway prototypes or experimental features until we can get some decisions agreed to on the requirements.
Estimations will be more accurate and easier to make when you make most big decisions up front. Project plans often fall apart because we add in new things during the process of doing the work. “Since we’re touching this part of the code base, might as well migrate it to the new build system,” “since you’re changing this page can you update the images,” and other such yak shaving. Use the estimation and project plan to bring such decisions to light, if not during planning then at the point they are made. This goes for product features as well as technical details. It’s fine to say yes and take the timeline hit, but being clear to all stakeholders that the timeline is changing to accommodate new work is part of the power of having a plan in the first place.
Estimation Rules of Thumb
You have 10 weeks of developer time per developer per quarter. 40 per year. Yes, that seems low. You will lose weeks to holidays, vacations, illness. You will lose weeks to training, reviews, new team member onboarding, company meetings, and other necessary company activities. You will lose weeks because something unexpected happened that pulled someone onto something else for a week or two. Trust me on this one. When you are doing estimation for a long project, estimate based on 10 productive weeks per developer per quarter.
At the micro level, never plan for more than 80% of someone’s time in a given week to be allocated to new deliverable project work. This roughly corresponds with our 40 weeks per year rule. There are always distractions and unexpected things happening.
When truly in doubt, double the estimate, but be real. It’s one thing for a one day project to take two days. It’s another thing for a two month project to take four months. If you need to double from two months to four months, it’s worth spending a few days drilling down on the project and articulating the pieces of it. You may find it will actually take 6 months. Or maybe you see a path through to get it done closer to 2. The doubling rule is a starting point and something to use when you’re put on the spot, but when the double rule causes a meaningful shift in project time, you owe it to yourself to invest some effort into breaking the estimate down more.
Why estimate at all?
I decided to put off answering this question in this article because the answer is very long. But in brief: You estimate because estimates help you think through the problem, they help you set goals, they help the team make choices about how to spend their time, and they are a powerful tool for managing the scope of projects.
Project estimation is not fun, I know. But in breaking down projects you will find that you start to understand systems better, that you learn to appreciate and manage risk and make the hard choices of prioritization. These are skills that all senior technical folks need to know, whether you’re a manager or an individual contributor, so don’t shy away just because it’s hard. That uncomfortable feeling is a sign of growth.
I’m writing a book on engineering management, coming out in early 2017. If you’re interested in hearing more sign up for my (very occasional) newsletter!
