We all know that software development estimation is hard, for many reasons:
- In and by itself, software development is too dynamic and complex for precise estimates.
- Estimates are perishable, even more so in Agile.
- Parkinson’s law, Hofstadter’s law, Goodhart’s law, and a dozen more eponymic laws prove that accurate software estimation is impossible.
These points are probably nothing new to you. They come to the fore whenever engineers talk about estimating software development. Yet, there’s one more stumbling stone that people don’t bring up that often:
In its core, estimation is communication between development and business, and the two really suck at understanding each other.
For software developers, estimates are approximate forecasts dealing with moving targets and unknowns. What a business person wants instead are concrete numbers. A vague forecast, after all, isn’t something you can put into a spreadsheet and send to investors.
Yet, estimation is extremely important both for business and engineering side so I’ve put together some practical advice on how to get better at it. I’ve grouped techniques I’ve seen successfully used on many projects into five strategies. Read on and find them below.
1. Estimate with ranges
“How long does it take to build a mobile app? How much time will you spend on UI development for my web app?”
We’ve all heard these questions. And we’ve all felt the temptation to begin explaining why precise estimation is so difficult in each of these cases. The problem is you simply can’t do that if you want people to appreciate your advice. After all, you’re not giving them what they are asking for… What you can do, though, is name a range.
Best case – worst case
When someone asks me how long a mobile app takes to develop, I usually say 3–8 months for a team of 2–5 people.
The range allowed by this estimate is very wide, from 6 man-months to 40 man-months. For 99% of the mobile apps that would be enough.. True, development rarely stops after 8 months but, this time is enough to bring the app from an idea to the App Store. This way, you can validate it with the market, which makes for a good definition of done in our case.
Ranges of allow you to keep your estimates actionable and true to life. Range-based estimates work for both project estimation and small tasks. And the best part, ranges with concrete numbers get people’s attention.
When pressed for a single estimate, name the worst case
… And remember to mention it’s the worst-case scenario. The penalty for overestimation is much higher than for underestimation, and it’s always better to over-deliver than to over-promise.
Estimate with time units, not story points
Story points aren’t inherently bad, but there are two major issues with them.
- First, story points are the most misunderstood — and misused — metric there is. Story points indicate relative team-specific velocity, which makes them non-transferable. Yet, companies often compare development teams based on how many story points these teams score per sprint.
- Second, you still need to measure time. There’s still a deadline set in time units, not story points. At the end of the day, someone still needs to convert relative story points into absolute time units. Considering the previous issue, do we really need this conversion?
2. Estimates are more precise when you start small and simple
Starting small and simple is a development strategy, but it also improves your estimation process. Specifically, it helps you to give palatable estimates and deliver on your promise.
Beginning with small features and the simplest implementation possible is great for the early discovery of pitfalls and potential bottlenecks. Besides, this approach lets you ship earlier, facilitating early user feedback. There’s a good reason why this is important for estimation.
For example, when building a web automation testing tool Screenster we wanted to be able to support on-prem and cloud execution. Building a scalable multi-tenant cloud version would have taken man-years. So we started by building only on-prem version and standing up a web page that allowed users to sign up for a cloud version.
We didn’t get cloud requests for the first 3 months. For the next 3 months we’d simply manually provide a private cloud instance for those users who did request it. Basically, market validation helped us decide to postpone the development of the complicated feature and focus on the features users actually needed at this stage.
User feedback shapes your backlog
User feedback provides a reality check that matters for project management and business. Whether positive or negative, user feedback eliminates unknowns from project estimation and narrows down your cone of uncertainty.
This has two important implications:
- Starting simple means both the technical and business implementations. In most cases, it takes everyone on the team to agree how simple you can get. Obviously, discussions of this sort should involve both developers and the folks from business.
- Getting early feedback on the most business-critical features will have the biggest impact on your backlog. Now, if only there was a reliable way to identify the features that are both small and business-critical…
T-shirt Sizing for early estimates
I’m sure you’re familiar with T-shirt Sizing. In the unlikely scenario that you aren’t, it’s an estimation technique popular in Agile. The smallest features that take under a week to implement get an S. If a feature requires 1–2 weeks of developers’ time, give it an M. Anything estimated at more than 2 weeks gets an L. Naturally, you can get more granular by adding other “sizes” like XS, XL, XXL, etc.
To estimate business value, ask the product team to do the same for each feature. The important functionality takes an L, the least important stuff gets an S. In the end, you get a matrix that looks like this one:
| Feature | Business value | Time |
| User registration | L | M |
| Dark Mode | S | S |
| User reviews section | M | S |
| User rating | L | S |
| IE support | S | M |
The features that get L in Business value and S in Time will get the highest priority. Simple as that:)
3. Decompose, then estimate
You always have better estimates if you decompose you features into smaller chunks. So once you’ve moved through ranged estimates and T-shirts and stripped down your early implementations, it’s time to decompose and count.
Breaking down the features from your to-do list can get different forms and shapes. In the simplest scenarios, your estimations will look like this on a high level:
| Estimation for: | Number | Days per item | Total work, days |
| UI screens | 10 | 3–5 | 30–50 |
| Backend modules | 4 | 5–10 | 20–40 |
| External integrations | 3 | 5–15 | 15–45 |
One thing to note: these don’t need to be super-precise at this point. An important idea with estimates is that they should enable you to move fast. There will be discussions at this point, as well as corrections introduced later on during future iterations.
Also, notice that using ranges will help you compensate for imprecision. You might not know how long the development of a particular UI screen will take. Still, you probably know how long a UI screen takes in average. And you know how much time developers in your team typically spend on really complex screens.
4. Don’t just be professional, look professional too!
If you view development estimation as communication, there’s a communication-centric maxim that influences software estimates. In a corporate environment, perceptual reality is reality. Consequently, your estimates are good only if people perceive them as such.
So how do you make your estimates look professional? One useful tool is Gantt Charts.
Gantt Charts
Most people have heard about Gantt Charts. Surprisingly, far too many teams forget about this tool and tinker with spreadsheets instead. So my recommendation mostly comes down to this: use Gantt Charts. There are many reasons to:
- Gantt charts help you organize yourself, automatically. Once you’ve estimated your features, how do know when you’ll get down to working on each of them? How do you time manage and prioritize between two similar-sized and equally important tasks? Gantt charts specifically address this aspect of development process estimation.
- Gantt charts provide a single source of truth on dates. Gantt chart tools automatically move dates as you add or remove resources. Should one of teammates vacation or sick leave affect your estimates and workload, you’ll know in no time.
- Gantt charts help you communicate your estimates nicely to executive management. A quick question: how much detail do CEOs typically from you? In 99% of cases, a nice-looking chart helps you keep things pleasantly high-level and substantially informative.
Speaking of detail, some aspects of software development projects estimation could go more in-depth. Namely, there are activities that developers often overlook when estimating their workload.
Estimate all activities, not just development
In far too many teams that I’ve seen, developers only estimate activities associated with feature development and bug fixes. So let me ask you: are you estimating the activities from the list below?
- Estimation
- Meetings
- Build scripts
- CI setup
- Demos
- Performance tuning
- Deployment
- Documentation
All of these eat up significant amounts of your time and effort. So if you’re not including them into estimation, you’re doing it wrong. Accounting for activities of this sort is both looking and being professional.
Underestimation versus overestimation
Remember the advice to name the worst case when asked for a single number? Estimates are rarely precise, which means you’re often at risk of finding yourself in one of the two scenarios:
- Your estimate was 70 hours, but you finished the task in 60 hours.
- Your estimate was 40 hours, yet it took you 50 hours to actually deliver a feature.
So which of these two scenarios are better?
Imho, neither of these is good. In the first case, you did better than expected. On the flip side, your estimate was off, so you don’t look that professional now.
Still, the second case is worse because there probably are people dependent on your estimate, and now they have more problems to deal with. Basically, the penalty for underestimation is almost always worse because it involves more people.
Besides, real-life progress on tasks tends to be in line with pessimistic, not optimistic scenarios which has been statistically proven by every study ever done. And I’m not even bringing up the Murphy’s law here.
So let me say it again, if you’re pressed for one-number estimate, it should never be your best-case scenario.
Bigger means slower
Choosing overestimation as the lesser of the two evils is part of being professional, rather than looking professional. Here’s another piece of advice that aids with being more professional. And it involves statistics, too.
Statistically, the same line of code will take longer to write in a large project compared to a small or a “from-scratch” project. The bigger the team, the more mess in communication. In the illustration below, each line represents a communication path between people in teams of different size:
5. Estimates work only if you control execution
An estimate may look bulletproof, but it’s not going to work out unless you proactively control the execution. In developers’ day-to-day work, there will always be things that creep in, threatening to ruin your performance. Someone adds new requirements. Your staff is less experience than expected. Someone asks you to work on something else in addition to the task at hand.
If you fail to communicate things of this sort, your estimates will be at risk. Best-case scenario, you met your deadline, but now you’re more stressed because you had more work on your plate.
Reporting these “extra” tasks is important. What’s even more important, however, is to report those cases when you know you might miss your estimate.
Whenever we realise we’ve underestimated, most of us will have multiple options. There’s an obvious option to work overtime, for instance. Some teams that I’ve seen start thinking if they can reduce scope. Finally, there’s a non-option of cutting corners by skipping unit tests (which many people choose, sadly).
So here’s another common-sense advice. Whenever you’ve underestimated and are considering your options, start with talking to your manager. Chances are there’s actually a way to move the date or add resources — you’ll never know unless your ask.
Bottom line: software development estimation is both science and art
Beyond doubt, it takes time and experience to learn how to estimate software development the right way. And it certainly takes a huge deal of project-specific knowledge. This includes both the knowledge of the product and the people building it.
So if any of the recommendations mentioned in this post don’t seem compatible with your case, just take what works for you. As in case with most things in Agile, nothing is set in stone when it comes to the estimation of software projects.
And if you’re looking for a team of seasoned professionals who are serious about estimation and timely delivery, contact us. AgileEngine ranks top-1 among the software development agencies in San Francisco, and the apps we build get featured by Facebook. We work with top-3% talent from Ukraine and Argentina, and we exceed our customers expectations 100% of cases. If this sounds like a bold statement, contact us and see if we can live up to it.
