Don'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.
In his cool video about effective estimations Robert C. Martin points to the following three pillars:
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.
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!
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:
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.
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.
The idea is simple: break your project down into tasks and estimate each task using 3 following scenarios:
You should make the following assumptions:
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:
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 |
The latter is calculated as:
Mean = (B + 4M + W)/6
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 |
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 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 |
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.
We highly recommend you divide your project into 20+ tasks to get more accurate and realistic estimate.
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/
Intersog, a leading technology partner, gains recognition on Clutch's prestigious list for game-changing software developers…
In the shift towards widespread remote work, the adoption of advanced digital tools marks a…
In the quest for innovation, the fusion of AI and Machine Learning with global remote…
In an era marked by rapid technological progress, the fusion of cloud computing and artificial…
Explore Intersog's unique approach to tech recruitment, offering a transparent, direct path to genuine career…
Explore the critical role and innovative strategies of efficient software maintenance for ensuring software stability,…
This website uses cookies.