Development teams see software estimation as a necessary evil. Of course, they’d rather innovate without the looming shadow of a client who must place cost and time ahead of function and design. But the tough love truth is — the world without software estimates doesn’t make any sense! We cover the importance of software estimation and how to make it work for you in this article.
The key takeaways:
- Despite their imprecise nature, we must get more accurate with our estimates.
- We need to improve communications with clients regarding what is and is not included in an estimate, and what is likely/liable to change.
Ready to get your hands dirty? Today, we’re taking a look at some of the most popular ways to formulate an accurate estimate, including the pros and cons of each.
Software Estimation Method No. 1: SWAG Estimates
Scientific Wild-Ass Guess (SWAG) estimates are based on very little information, but they are an important part of approximating cost and time because they help development teams prioritize features. We call this prioritization a Rough Order of Magnitude (ROM).
The Fermi Estimation (coined after it’s inventor, a Nobel prize-winning nuclear physicist) is one of the most popular forms of SWAG estimation.
How To Fermi Estimate
- Step 1: Make high-level assumptions about what the project needs.
- Step 2: Approximate everything. How long? How many? Etc.
- Step 3: Combine your assumptions and approximations. Do basic math to reach cost and time totals.
Fermi Pros: This method is arguably the fastest way to reach a reasonable estimation.
Fermi Cons: What you gain in speed you lose in accuracy. Fermi estimations are only as accurate as your approximations, and in most cases, approximations are “off” to some degree.
Software Estimation Method No. 2: Top-Down Estimates
Also referred to as “analogous estimates” or “parametric estimates”, this method involves closely comparing a potential project to a previous project with extremely similar specifications. Top-down estimates depend on expert knowledge of the work involved and plenty of historic data. Historic data enables your team to size up individual work items based on complexity compared to other items.
Estimators can expect certain parts of the project to factor out quickly and easily, but be prepared — inevitably, you will need to make assumptions. Make a note each time an assumption is made; this will ensure estimation accuracy.
Pro Insight: Effort does not increase linearly. If you are estimating a project that is twice as big as the project you are using as a comparison, don’t assume that it will take twice as long to complete. It will take longer.
Top-Down Pros: This methodology is reliable when strong analogs and historic data are present. They’re fast and cheap, and they don’t require extensive effort (referencing old data cuts back on time spend).
Top-Down Cons: If you don’t have strong analogs and historic data, this estimation won’t provide much accuracy. It’s also easy to miss key complexities if you fail to think through the beginnings of a design and implementation.
Software Estimation Method No. 3: Bottom-Up Estimates
Also referred to as “detail-driven estimates”, this method is more difficult than the others, but also more precise. Bottom-up estimates depend on your team’s ability to break down a project into a series of smaller segments that you can estimate with higher precision. The goal is to develop a list of features (organized by complexity) and estimate how many hours each feature will take to design and build.
How to Bottom-Up Estimate
- Step 1: Break the project down into smaller components. Your design team should be highly familiar with these components, the thought being that if your team knows how to do them (and does them often), they can more easily and accurately estimate time/cost.
- Step 2: Create a list of all assumptions about the project requirements.
- Step 3: Estimate each component.
- Step 4: Add up the estimates.
Bottom-Up Pros: This methodology is your most accurate approach to estimating because it deals with project components at a micro level, which makes them easier to wrap your head around. If you mix in a little top-down methodology and incorporate analogous and historic data, you can push accuracy even closer to reality. The unspoken perk of bottom-up estimates is the fact that they’re traceable; built from a list that covers your scope and all assumptions. As project details change (and they will) you can easily reference this list, make adjustments and see how changes impact time and cost.
Bottom-Up Cons: This type of estimate takes significantly more time and effort than other forms of approximation.
Summing Things Up
Fermi estimations are great for getting project talks moving in a more substantiated direction. But this type of estimation lacks rigor and leaves much to change.
Top-down estimates are far more accurate than Fermi estimates, and ideal for situations where the same type of work is repeatedly done. But they aren’t necessarily ideal for mapping out cost and time at the project level.
Bottom-up estimates are your best bet when accuracy is essential, but be prepared to spend serious time and effort mapping out your approximations.
If you only remember one thing from this article (though we hope you remember more) it’s this: Never, ever, ever give an answer without building some type of formalized, documented estimate.