A few years back, a colleague shared an interesting exercise with me. He took a deck of cards, split it in half, turned one half face up, then mixed all the cards up on a table and asked me how many seconds I thought it would take me to group them by suit and sort each group from low to high.
“I have no idea,” I said.
“Yet you have everything you need to give me an estimate,” he replied.
I conceded there were a fixed number of cards, that I had played cards many times before, and that I understood the definition of “done.”
Still, my guess was wrong by a significant margin.
We agreed (and proved) that the second time I would be closer. But I never hit on exactly how long it took; sometimes it took longer, and sometimes I finished sooner. We concluded I was unlikely to ever get it exactly right because there were a number of variables outside of my control. Where were the cards divided? How many landed face up? Even the level of distraction I encountered while sorting mattered.
The same is true when it comes to estimating software. It’s not an exact science. It is, however, a science. The key is to approach custom software estimation with rigor and discipline. Over the 20 years, I’ve spent working as a software engineer and solutions architect, I’ve found successfully estimating complex software projects depends on four fundamental concepts:
1. Knowing which approach is appropriate for where you are in the software development life cycle (SLDC)
2. Quantifying risk
3. Understanding (and communicating) the accuracy of the estimation
4. Continually refining
Techniques For Estimation
I’d be remiss if I didn’t point out that there are a myriad of ways to estimate software development. The three I have chosen to explain are those I’ve had the most success with. I don’t believe there is one right way to estimate software development, but there are a lot of wrong ways to do it. As a technical leader, your job is to find what works for your organization.
1. Analogous estimation generally occurs at the proposal stage. You can do this by collecting similar scope from one or more projects you have delivered on previously and combining the historical actuals. While analogous estimations are typically the fastest to pull together — usually they take just a couple days — they require experienced teams and tend to have the least accurate output.
Use analogous estimates to make sure you and the stakeholders are on the same page before either of you invest more time in next steps.
2. Top-down estimation works best with a set of wires or a clickable prototype. This technique relies on using known data points for specific parameters that impact complexity. For example, you may need to know the number of screens, the number of third-party integrations, the number of supported browsers and so on for your software.
Once you’ve created an estimation model for a domain, top-down estimates are quite powerful as they don’t take nearly the amount of time as a bottoms-up estimate but are more accurate than the analogous approach. If you’re using top-down estimations at your organization, make sure to keep refining your estimator. As you deliver on projects, feed the actuals back into your model to improve future accuracy.
Top-down estimates typically require two to five days to prepare.
3. Bottoms-up estimation should be a part of every project. It is usually appropriate following a technical discovery. This technique requires a work breakdown structure (WBS), which breaks a project down into smaller parts that you can estimate, and generally works best if the actual people on the team who will be doing the work create the estimates.
A bottoms-up estimate is by far the most accurate, but it is unusual outside of a complete waterfall environment that the team will have the inputs required to do this exercise until four to eight weeks into the actual project. Expect the team to spend 5–10 days just preparing the estimations.
While it is impossible to know exactly what the impact of risks will be, the most responsible way to estimate is to identify and then apply an appropriate contingency.
There are many risk factors, but some you should consider are:
• Overall size of the project
• Number of users at scale
• The number of technology stacks
• Regulatory, compliance or security constraints
• Whether or not the team is geographically distributed
• Number of external dependencies
• Your team’s experience with the specific technologies and delivery methodology
• Maturity of the technology chosen
How much these factors impact the overall estimation is something each organization has to get comfortable with. Anywhere from 3% to 15% is typical, in my experience. Contingency is applied on top of the total estimation and doesn’t change the fidelity of the estimation. Contingency usually manifests in the project as additional resources or time.
Think of fidelity as the likely margin of error in an estimate, similar to the fine print when various polls are reported in news outlets. In software development, because of all the reasons mentioned previously, the margin of error tends to be higher than in other industries. I’d argue consistently estimating software projects to plus or minus 20% is one hallmark of a world-class software organization. I usually suggest the following:
• Analogous: +/− 40%
• Top-Down: +/− 30%.
• Bottoms-Up: +/− 20%
To successfully estimate any software project, you should continually tune the estimate. The worst-case scenario is learning the timeline or effort has changed after it’s too late to do anything about it. I ask my teams to reevaluate the estimations every couple of sprints. You’ll find that by approaching estimations iteratively, you can manage expectations, scope and ultimately budget.
Software development projects have a reputation of always taking twice as long and costing twice as much. There is some truth to that. Estimating software is not easy. Like most things in life, experience plays a large role. Estimation takes time and effort, and as such, is an investment that you should factor into software development efforts of any substance. The role of technology leaders is to foster a culture of thoughtful, measured approaches to estimating software projects.