As a Principal Web Developer at Stack Overflow and a long time Tech Lead, I learnt that accurate estimates were essential in order for a company to be healthy and productive. Over the years I have spent a good deal of time developing my theories for why estimates and breakdowns are so important, and crafting my own methodology for how best to go about doing them.
Below, I attempt to distill the lessons I’ve learned so that others can experiment with and improve upon my techniques. Now, I should be clear, the advice below is what works for me. I’m sure there are different approaches that might work better for others. Feel free to share your favorite approach in the comments.
Why are devs asked for estimates?
The impetus to provide an estimate for development work most often comes from non-developer stakeholders in your organization. An estimate helps to plan and coordinate product releases, synchronize work with other teams, ensure that resources are allocated properly to meet the needs of the product, and of course to enable accurate billing of clients when your team has been hired to do a job for an outside company.
Given that list, it’s clear there are many legitimate reasons why you will be asked for an estimate. And due to a number of reasons (guilt, good intentions, pressure from the estimate requestor) you might even give a best-guess estimate. However, as many of us have learned, while it is easy to give someone a number, it is much harder to give a number that is in any way accurate. And due to the dependencies that others put on the provided number, a bad estimate can sometimes do more damage than no estimate at all.
What a good estimate provides
By dint of its prerequisites (and the level of organization and planning they require), an accurate estimate will enable you to deliver your work with a high level of quality in the least amount of time. It will help you to avoid false starts and the pain of having to throw away code unnecessarily. It will help to minimize scope changes. It will allow you to structure and to plan out your work in the most efficient way that you can, and will also help all of the other stakeholders mentioned in the previous section out immensely.
Estimating Rules
So how should you do estimates? Estimation technique is a personal decision that each dev has to make for themselves. Recommendations will be made below for different techniques that have worked for different people in the past to come up with the final estimate.
That said, here are some guidelines that are important to follow (regardless of the estimation technique).
Never write code unless you have a good understanding of what functionality is required
While this is not something that directly relates to making the actual estimate, it is at the top of the list because it is such an important factor in writing quality software that actually does what the client needs it to do. Beyond the benefit to others that an accurate estimate provides, the main artifact that an accurate estimate gives you is the confidence that you know what you are working on, that you have thought about the different issues that may arise with architecture and implementation, and that you have taken these into account in breaking down your work and making the estimate.
Always estimate off of a spec
An estimate that is not based off of a strong understanding of the functional requirements will most likely result in an inaccurate estimate, as it will not account for all of the required functionality. Even if there have been meetings to talk about what is needed, unless it is written down and all stakeholders have agreed on its contents, it should be assumed that one of the stakeholders understands the requirements differently from the others.
If the spec has unanswered questions, or missing details, don’t commit to an estimate for or work on that section
An important part of the spec-writing process is reviewing the spec and asking questions as needed. Take the time to cover edge cases and implementation details that will impact the functionality. Call out sections that are missing important details (these are often the most complicated sections on the spec).
Spec-writing takes time, and sometimes there are requirements that are not understood until later on in a project. That is fine and acceptable. The consequence of this is that the incomplete sections in the spec cannot be given an accurate estimate.
If the estimator has not thoroughly reviewed the spec, the estimate will not be accurate
Without reviewing the spec, the estimator is simply not properly equipped to make an estimate for completing the functionality that is required by the client. There is no real way around this—coming up with an estimate in these circumstances has a very small chance of actually relating accurately to the work that needs to be done.
The developer doing the work should perform the estimate
An estimate that is made by someone other than the person who will be doing the work is much harder to get correct. Even if the estimate is based on a complete spec that the estimator understands, it will still have some major shortcomings:
- Every developer works at a different pace, so one dev’s estimates will normally not be transferable to a second developer.
- Every developer will break down and plan their work differently.
- Different devs have different sets of domain knowledge, which also makes time estimated to learn/understand consequences very different for changes (and if you don’t have the domain knowledge, be sure to account for the extra time needed in your estimate as well).
- If the developer doesn’t do the estimate, they have missed out on the extremely valuable step of planning out the project execution, something that can contribute greatly to avoiding unnecessary work and delivering features on schedule.
Keep the spec and estimate up to date throughout the course of the project, including scope changes
Ideally, the spec and estimate should be kept up to date through the course of the project as requirements and scope changes. It will be indispensable for performing QA properly and will serve as a very handy reference for anyone who needs to learn more about the functionality in the future.
Discipline
Do not let yourself be bullied into giving a full estimate for sections that haven’t been properly defined
Once you reach a stage with stakeholders where people have bought in to having the developer be the author of the estimate, this can lead to a situation where pressure is exerted to commit to an estimate for work that has not yet been fully defined. This common scenario can happen with the best of intentions. Plans need to be made, and often they need to be made by those who do not have a direct way to move along the definition process. And when those plans rely on estimates, it can leave the developer in a hard place.
In this scenario, it is important to be very clear: an actionable estimate must be based on well-defined work. It is important to make this clear to the stakeholder. And while doing so, be sure to highlight that you want to give them a reliable estimate, and doing so without knowing the full scope of the work will almost surely result in an estimate that is not reliable. In cases of need, you can always provide a greatly inflated, worst-case-scenario estimate, but this should be avoided, and when you must, be sure to let the stakeholder know that the estimate itself can be updated and made more accurate once more details on project definition are known.
Do not mold an estimate to meet externally-dictated time expectations. Drop features instead.
Another uncomfortable scenario that can occur is when a stakeholder attempts to dictate what the estimate needs to be, based on external dependencies or other business requirements, even when this is at odds with the real estimate. The hope is that getting the developer to commit to this estimate will ensure that the work will be done within these time constraints (or if not, that the developer can be held responsible for missing the deadline). As should be clear by now, any estimate that is not based on a realistic breakdown of well-defined requirements should not be deemed reliable or, in fact, be given at all. In this scenario, the proper response is to negotiate scope for schedule. As in: if you want to release by this date, then we need to cut the amount of work that will need to be done. Hold firm and keep bringing the conversation back to your desire to provide an estimate that will be accurate and reliable for everyone involved.
Translating hours into days: be realistic
Your estimate should end up setting a number of hours to complete the defined tasks. For planning purposes, you will often be asked early on in a project how many days of coding will be required. I find it’s more accurate to create granular estimates in hours and to translate the total hours into a number of days. In doing so, be sure to factor in things like other duties (bug duty, other projects), management responsibilities, vacations, and holidays. Also be sure account for routine tasks that the developer needs to do (meetings, email, spec reviews, planning). I have found that assuming any more than 6.5 hours of productive project work a day can result in a mismatch between productivity expectations and actual results.
Make your breakdown and estimate public and ask for feedback
Once you have your breakdown and estimate complete, it is best to post it online and share it with your PM and team members. Even if they are less familiar with the details of the spec than you are, other people may see holes in your breakdown or may be able to raise questions about estimates for specific items that you had not thought about. Remember: it becomes exponentially more expensive to fix things the further along you get in a project. Changing a line on an estimate is cheap. Rewriting a module from the ground-up is not. Take the extra time to solicit feedback.
Posting estimates publicly (and keeping it up to date with regards to task completion) also makes you more accountable for your progress (in a good way). A responsible PM will check on your progress periodically, especially if it looks like things are stalled (a scenario where you should be in open communication with the PM anyway).
It is ok to give an estimate range along with a confidence scale
If the entire spec cannot be completed in time for the estimate, give a full estimate for parts where you can and range/confidence for sections where the spec is incomplete. Use your judgement: you might be asked for a 100% confidence estimate on a large project, but if the spec isn’t ready for that, then be clear about what your estimate covers. It is much better for everyone in the long run to say: 60-100 hours with 60% confidence than to say nothing or to make up an exact number without basing it on anything. And then as the spec becomes more complete, the estimate should follow suit.
Risk mitigation and accounting for iterations on larger projects
Large projects (arbitrary definition: projected to take over two months, though this can vary) come with their own set of challenges. They will have larger estimates (and therefore more opportunities to mess up the estimates), they will have more people relying on the projected release date for whatever their dependency is, they are more likely to have large specs where not all functionality is defined up front, and they are more likely (at least in some domains) to have cycles of release/iterate. How does one account for these in estimates?
While every project needs to be addressed based on its own needs, the general approach for large projects featuring iteration should be to use the guidelines stated above on both a macro and micro level. If the very large project has one section of work fully defined in the spec and the rest of it loosely defined, then make a breakdown and estimate for the first section. If a full estimate is needed for the entire project, then make a very conservative estimate for the whole thing based on what you know of the functionality, attach your assumptions and confidence in the number, and continue to pursue getting the entire spec completed and all of your questions answered.
This also applies to iteration: if the project planning calls for a continuous release cycle, with features being constantly refined and redefined throughout the iterative process, this is something that by definition will be extremely challenging to accurately estimate up front, as at the starting point there is no defined functional requirement. In a situation like this, you just cannot be as confident in an estimate as you would be with a full functional specification. If this is the reality and you are requested to give an up front estimate, there is nothing to do but to estimate very conservatively for the ill-defined sections, noting your assumptions and confidence level. Unfortunately, these situations are sometimes unavoidable—what you can do to mitigate the potential damage of a bad estimate is to continue to pursue a full functional specification while being very clear about the limitations there are on any estimate that you provide such that all parties are as well-equipped as possible to deal with it.
Be sure to include time for pull requests, testing, and release issues
This is something that is very easy to forget about, and leaving off time for pull request testing and product release (especially when these are non-trivial) can leave a sour taste in everyone’s mouth when features are delivered on time and then the last stage of QA and release end up dragging on and on. In scenarios where PRs are a required part of the process, and especially when they bottleneck on very busy reviewers, the time that they add to an estimate can be non-trivial. While it doesn’t necessarily add to the amount of developer time (though it could, based on the quantity of feedback), it will add to the delivery time. A responsible developer should take care to take these factors into account in their planning and when making commitments as to deliverables, based on the specifics of the project responsibilities (for example: who will be reviewing PRs, who owns QA, what will be involved with the release, etc).
Techniques
The best estimates involve breaking down the work to be performed into small tasks—the smaller the better. Estimate the tasks, break them down, and repeat until they get small enough. This is the essence of a very thorough and accurate method for estimation. Establish a goal for granularity. I recommend two hours maximum, and break down tasks until you hit that across the board. If you have a task over the threshold, break it down further. Then sum it all up.
There are various tools that you can use to help for organizing this. I prefer using Trello cards (one per main task with a checklist for a subsection and checkboxes for granularity) though this does require manual calculation of hours. You can also use Excel, MS Project, FogBugz (or one of many other project-organization tools out there). The most important thing is that you use a tool that works for you and your process and that does not add organizational overhead.
There are other approaches to estimates out there (I go into more depth on estimation practices in this article). Especially in the agile world, from Planning Poker to many others. If this works for you and helps you to get an accurate estimate, then go for it. Just remember, it can be risky to rely on techniques that take the onus of estimation off of the developer who will be doing the actual work.
Do you have thoughts on how best to provide estimates so developers and dev teams can work with the rest of their organization? Let us know your tips and tricks in the comments.