Custom Software
AI Solutions
Hire TalentDon't you agree that fast software project estimation is like fast food: cheap and harmful, yet inevitable when there're no other options around? Did you ever have to estimate project you never heard about before in 3 hours or less? Here's our 5 cent regarding how to estimate projects fast and accurately. While there's no one size fits all method, you can indeed estimate projects fast and effectively, and let us show you how.
Project Estimation Requirements
In his cool video about effective estimations Robert C. Martin points to the following three pillars:
- Honesty
- Precision
- Accuracy
Honesty
WTF is honesty as far as software project estimation? Not lying to the client about how much it'll take you to build their software solution. That's pretty clear.
Precision
If you estimate 3 similar projects, you should come up with 3 similar estimations. Let's say it took you 1 man-year to build a robust CMS system from scratch in the past. If you have to estimate another CMS dev project, it can't take you 3 man-weeks or 2 man-years to execute the project!
Always make sure your figures aren't contradictory and don't question your professionalism and common sense. A basic RESTFull service can't take longer to create than a self-taught AI service for analytics.
Inadequate estimations can undermine your credibility and reliability as a service provider. No trust - no project is a rule of thumb!
Accuracy
Your estimated delivery deadlines should be accurate which means the difference between the actual and expected build time should be minimal. If you do say the project will take 3 months to execute, you should mean this! It should take exactly 3 months, not 6 or 12 months whatsoever.
Estimation accuracy is a tough cookie, no doubt. The reasons for this are:
- Time constraints - you usually have little time to estimate project especially if you work closely with your sales team. These guys need all at once and they pressure you to hurry up with the estimates. Doesn't it feel familiar?
- Lack of details - you don't have full information about the functional features, target audience, etc. Sometimes all you have is a couple of paragraphs of poorly written and bloated text. Or napkin notes at best. Brace yourself for working with very limited input data. To get more information you need more time and this is the luxury you can't afford!
Also keep in mind that your estimate accuracy increases exponentially as you add more man-hours. That being said, even if you have more time to estimate the project, your final estimation will still contain a bias which can be rather serious.
Bottom line
Honest, precise and accurate project estimation sounds like this:
The project will take 6 weeks, probability of success is 95%. Alternatively, it can take 4 weeks with 65% of chance of success.
You can also show the project estimation as a range of values:
The project will likely take 4 to 6 weeks with 95% probability of success.
Three Point Estimation
The idea is simple: break your project down into tasks and estimate each task using 3 following scenarios:
- B - best case (optimistic): 95% chance of success
- M - most likely: 50% probability of delivering on time
- W - worst case (pessimistic): 5% chance of success
You should make the following assumptions:
- The chance of realizing an optimistic scenario is very slim or close to zero. Consider it as your big-omega.
- The most likely estimate is the most realistic one; consider it as your big-theta.
- The pessimistic scenario is based on the assumption that everything will go wrong on the project. It can happen if, say, your whole team falls apart amidst the project or someone breaks in your office and steals all computers and puts a huge spoke in your project wheel. Consider it as your big-o.
Check out How To Estimate Software Development Project In Man-Hours Realistically.
Let's imagine the following case. You have a project with the following requirements:
The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.
Let's assume we've broken it down into the following tasks:
- User login
- Purchase commodity
- Purchase history
Your three point estimation will look as follows:
| # | Task | B | M | W |
|---|---|---|---|---|
| 1 | user login | 50 | 150 | 500 |
| 2 | purchase commodity | 75 | 200 | 750 |
| 3 | purchase history | 10 | 50 | 100 |
Estimating weighted arithmetic mean
The latter is calculated as:
Mean = (B + 4M + W)/6
Would you like to learn more
about talent solutions
Why do we use coefficient 4 for nominal case? Because it appears to be the most realistic one. To estimate project total mean we should sum up the average duration of each task. See example below:
| # | Task | B | M | W | Mean |
|---|---|---|---|---|---|
| 1 | user login | 50 | 150 | 500 | 191.67 |
| 2 | purchase commodity | 75 | 200 | 750 | 270.83 |
| 3 | purchase history | 10 | 50 | 100 | 51.67 |
| Project total mean | 514.17 | ||||
Estimating project standard deviation
Use the following formula to calculate standard deviation (S) for each separate task:
S = (W — B)/6
To estimate total project standard deviation, use this formula:
Project Standard Deviation = SQRT(SUM(S)^2)
For our imaginary project the picture will look as follows:
| # | Task | B | M | W | Mean |
|---|---|---|---|---|---|
| 1 | user login | 50 | 150 | 500 | 191.67 |
| 2 | purchase commodity | 75 | 200 | 750 | 270.83 |
| 3 | purchase history | 10 | 50 | 100 | 51.67 |
| Project total mean | 514.17 | ||||
| Project standard deviation | 202.5 | ||||
Beta distribution
Beta distribution is fundamental in project evaluation and review technique (PERT), so why not use it for quick estimations? Beta distribution is used to calculate probabilistic estimation value.
In our case we'll have the following values:
| Chance of success | Probabilistic estimation value |
|---|---|
| 95% | 884.90 |
| 70% | 612.24 |
| 50% | 490.48 |
Estimating range value
If all the probabilistic stuff is still a rocket science for you, you can alternatively indicate a confidence interval for true project execution time using the following formula:
Project Total Mean ± 2 × Project Standard Deviation
Coefficient 2 is based on 68-95-99.7 rule.
In our case, if chance of success is 95%, then the project range will be: 311 (lowest bound) - 919 (highest bound) hours. If chance of success is 68%, the range value will be 109 - 716 hours.
For your project specific calculations please use this Excel Workbook.
We highly recommend you divide your project into 20+ tasks to get more accurate and realistic estimate.
Conclusion
IT project estimation is usually tough. Although three point estimation and beta distribution are far from being perfect methods, they can give you more confidence in your estimation precision. And the more confident you are when talking to a prospective client, the higher the chance they'll pick you as a service provider. So good luck with your quick project estimations and make sure they're always honest, accurate and precise!
Inspired by dou.ua/lenta/articles/quick-estimates/
