Software projects are notoriously difficult to estimate accurately. After years of building successful custom software projects, I’ve learned a lot of helpful DOs and DON’Ts for creating accurate estimates and had the opportunity to test those rules over hundreds of software projects during that time.
Below I share of few of those tips which I have found the most important and useful for me to keep in mind when creating estimates.
So, let’s jump right in…
WHEN ESTIMATING SOFTWARE, DO:
Estimate as small as possible, or maybe not at all
Sometimes the best estimate is no estimate. How do you know if you really need one or not? Well, the need for an estimate can be for many different reasons, but make sure to stop to think first to make sure you know where that requirement is coming from for you. After some reflection, if it’s not obvious why you’d actually need an estimate, consider skipping it. Most examples of why you might need an estimate usually relate to the fact that other decisions can only be made with a timeframe attached (like when to start selling a new software product) or in our case at Trailhead, because our clients want to know how big of an effort they’re committing to before we start. If any of those reasons are true for you, then you might need an estimate.
If you have a software product you’re maintaining, maybe you just need an estimate for a single new feature. If so, make sure you’re estimating as little as you can to be useful for your business. Any more will only cause you problems.
Remember meta-tasks like setup, code reviews, and team meetings
Once you’ve decided you do need an estimate, don’t forget about all the tasks related to setting up and running a project. For example, developers may need to set up their development environment, they may need to meet together to discuss a particularly tricky feature, or they may have a newer team member whose code needs some extra review by a more experienced team member. If any of these tasks need to be done on your project, don’t forget to add them to your estimates.
Break it down as small as possible
This might be the most important tip on this entire list. If you’re building a project and you’ve created an estimate only at the level of the entire project, you are probably missing a lot of details that you haven’t accounted for in your estimate. The best way to avoid this problem is to break the work down into every possible sub-task (and sub-sub-task) that you can think of, estimating each of those sub-tasks, and only then rolling those estimates up to a total for the entire project.
Include non-development tasks like design, project management, and testing
You’d be surprised how often developers forget that there are people with other disciplines that need to do work on their software project. For example, designers, project managers, and testers. If you’re going to have an accurate estimate, make sure you include the work for everyone that will be working on the project, not just the developers.
Remember to multiply tasks when multiple people are involved
A common mistake I’ve seen in estimates is forgetting that some tasks require more than one person simultaneously–sprint planning, estimation, sprint retros, code reviews, trickier development tasks, some debugging, etc. If you have any of these as a type of work for your project, don’t forget to multiply the time for these tasks by the number of people participating in them.
Have experienced engineers involved in the estimate
If your project is a mobile project, make sure an experienced mobile developer estimates it. If it’s a web project, make sure it’s an experienced web developer. It may seem obvious, but when people create an estimate who aren’t intimately familiar with the underlying technologies or frameworks, they’ll often miss things…sometimes a lot of things.
Double-check with a second set of eyes
It can sometimes be helpful to have two different people estimate a task or set of tasks independently and then compare their numbers at the end. Some teams might find it helpful to go with the highest estimate for any given task. Other teams might get more value from talking it out, understanding why their estimates disagreed, and coming up with a new number together.
Gut check the end result
Something I like to do to make sure an estimate is a good one is to check the final result using a different estimation method. I might take the total time and compare that to my original rough expectation for the project or use my experience from similar past projects to see if the estimate came out in the same range.
Think of each estimate as a range, not a single number
Estimates that result in a single, seemingly magic number for how long the work will take often give a false impression of certainty. Instead of producing a single number, why not capture a range of possible numbers? This allows the business to plan for all likely scenarios from the best to the worst case.
Think about who will be doing the work
The danger of having an experienced developer do all the estimates, as I recommended above, is that those developers may actually be much faster than other developers on your team. Work with your most senior team members to think about who will actually be doing a chunk of work that they are estimating, and make sure they are estimating the time for that person to do it, and not for themselves.
Leave time for unexpected work
Plan for the unexpected, because we know that it will come up in any project. Pick a fixed percent–25%, for example–of your estimate total as a starting point for unexpected work, then measure the actual hours spent on tasks that are not in our original estimate. At the end of the project, compare that unexpected work to the estimated amount, and tweak the percent you use for future projects to be more accurate. By the way, if this number stays at a very high percentage, you might need to work more on the other tips on this list, such as breaking the problem down into smaller pieces, to help improve the overall quality of your estimates.
Phase the work
Not only can you break a project up into sub-tasks to get a more accurate estimate, but often you can also set milestones within your project to break the work up into useful phases. This is valuable because the larger an estimate is, the more likely it is to be inaccurate. Better to estimate just phase 1 of a larger project, ignore the later phases, and come back after phase 1 is underway (or already completed) to estimate the next phase. You’ll often find that the tasks you end up putting in later phases are different than the ones you would have if you’d estimated it all at once upfront.
Planning Poker and Other Planning Games
There are several games you can play with your team to help improve their estimation skills and to rely on the knowledge of the crowd. The most well-known of these games is planning poker, but others exist as well. Experiment to see what works best for your team.
WHEN ESTIMATING SOFTWARE, DON’T:
Use a catch-all multiplier
This is a common “hack” I’ve encountered with teams that have repeatedly failed to make accurate estimates. The thinking seems to be that, if the manager simply takes the numbers she gets from the developers and multiplies them by 2 or 3 (or 10), that they will at least not be too low. The first problem with that thinking is that, if your team is missing most of the sub-tasks for example, you don’t know if you need to multiply by 2 or 100 to make up for that. The other issue is that, even if you manage to estimate more than the actual time needed, you still don’t know if it’s accurate or not, so you can’t safely base any business decisions on it.
Share the results without a walk-through
Whether your customer is internal or external, don’t send your estimate to them without a chance to walk through it line-by-line. Without context, your estimate is very likely to be misunderstood. It’s best to talk through it with stakeholders in detail so they have a chance to ask questions and challenge assumptions. At Trailhead, we schedule a meeting to review our estimates with all project stakeholders, and only after that do we email a copy of the estimate.
Confuse person-time and calendar time
Most projects involve the work of more than one person. Sometimes that works is sequential, sometimes it is not. Remember that a 160-hour estimate may or may not take one month to implement depending on how many people are working on it and how much of the work can be done in parallel.
Ignore your % under/over on similar past estimates
One of the most useful tools you have in getting an accurate estimate is your previous estimates. If you track actual project time against your estimates, you can slowly improve your accuracy over time. Look for patterns like certain estimators always being too optimistic or certain tasks always being forgotten and apply those lessons to your next estimate.
Assume exclusions
Think about what someone might assume is included in your estimate if they are not reading it carefully, slowly, or with their full attention. If there is anything that could seem like it’s included, but which isn’t included, make sure you explicitly mention it in a list of exceptions. Make them very noticeable, and point them out when you review your estimate with stakeholders. This gives everyone ample opportunity to correct any mistaken assumptions.
Estimate without a design or detailed requirements
One of the most powerful tools in an estimate is a visual design. The human mind is clearly geared for processing visual information, which makes it the clearest to communicate with other humans using visual examples. If you can mockup or design the user interfaces of your application before the estimate, it will remove a lot of misunderstanding and inaccurate assumptions from the process. It also greatly increases the chances that all the estimators know exactly what they’re estimating, that the implementors build the same thing that was estimated, and that the thing built is what the stakeholders wanted.
Those are several of my most useful estimation tips. Do you have any other good ones? If so, leave them in the comments below.
