There is no definitive answer to this question, but in actual it’s a combination of both. When art and science are mixed together then only the accurate or realistic estimates are achieved. Let’s go through this in detail in this article.
Before we drill down into art and science pieces, lets quickly go through different type of approaches or methodologies available for software estimations.
Types of Estimations
Top down Estimation
Top down estimation approach is to start from the project vision and goals, break them down in to smaller or granular requirements or modules or features (different names used by different companies/teams). Each of these modules are further broken down into work packets, which are estimated and planned and then assigned to team members for development or execution.
- Benefits of top-down approach – major tasks are quickly identified, and details are defined at later stages.
- Common top-down estimation techniques – Use Case Point Estimation, Function Point Estimation
Bottom Up Estimation
Bottom-up estimation approach is to start with defining list of tasks required to achieve customer goal, and then group these tasks together to form modules. This approach is more a team activity, rather than done by a single person. Whole team contributes in defining different tasks and then grouping them together.
- Benefits of bottom-up approach – results give more detailed schedule, but it’s also a time-consuming approach compared with top-down estimation techniques.
- Common top-down estimation techniques – Wideband Delphi, WBS (Work Breakdown Structure)
|Factors for Comparison||Top-down||Bottom-up|
|Granularity of Estimates||Low / Medium||High|
|Granularity of Requirements required||Low||High|
|Cost of doing estimates / Estimates turnaround time||Low||High|
|Level of Assumptions made during estimation||Medium||Low|
What’s the Estimation Process?
Let’s go through estimation process step by step,
Any estimation starts with a set of requirements. Quality of requirements plays a major role in defining the quality of estimates. If requirements are of low quality or at very high level, then there will be more assumptions made while doing estimates and you will see more variations in planning and estimates at the time of execution. More granular the requirements, better the chances of having accurate estimates.
Second stage is estimation, where not just requirements but Influencing factors are also one of the input. Influencing factors like team dynamics, skill set availability, team experience, etc. plays major role in defining estimates. Such as, if current team doesn’t has technical skill to deliver this kind of project, then obviously team will take some time to ramp-up on required skills, that becomes one factor to your estimates.
Another major input is historical data – if you have delivered similar kind of engagements in the past, then you should refer actual execution effort for those past projects, and that will help you quickly estimate for these new requirements. And that’s where the science portion of the estimation comes into play, where you refer historical data and not completely dependent on your subject matter experts (SMEs).
Third stage of estimation process is capturing actual execution time and effort at the time of build/execution phase, and maintaining that actual execution effort as company’s historical data. This is the most important activity and most of the companies don’t prioritize it and misses it completely. And that directly results in their lack of historical data, which ultimately results in long estimation times during pre-sales cycle and team’s lack of confidence on estimates, as they always have to be completely dependent on their SMEs for estimations.
While we are discussing Historical Data, lets also look at what all goes into that historical data after the project execution,
- Size of the Project – it’s up to you how you want to define size of the project, it could be in terms of number of requirements categorized along with their complexities, or size in terms of Functional Points, Use Case Points, etc.
- Type of Project – this can be defined in terms of domain perspective or technical perspective. Such as, project is categorized as insurance domain or manufacturing domain, etc. Or project type could be more technical in nature, like it’s a website development, or a IoT (Internet of Things) project, etc.
- Total Effort – effort is a measure of time, i.e. total time spend by the team in terms of hours or days or months.
- Total Cost – total cost of the project, which will not only include team’s effort, but will also include other expenses like travel, software licenses cost, hardware cost, etc.
- Duration – depends on what methodology you use, like Waterfall or Agile, always capture duration of each phase/sub-phase of the execution, rather than just capturing total project duration.
Some Common Pitfalls During Estimation
- Targets are treated as Estimates – Initially targets should always be kept different from estimates, don’t confuse targets as estimates. After base estimates are ready, then there should be iterative process to bring target, estimates and scope into alignment.
- Committing estimates too early in the Cone of Uncertainty – if you don’t have requirement clarity or scope clarity, then it’s a good time go back to stakeholders and get requirements clarified, before you start estimation.
- Not using any Estimation Software – having any software estimation tool is a must for any organization. This is the tool that will help you manage historical data, and help your estimators/SMEs to come up with standardized estimates and streamline your organization’s estimation process. Otherwise everyone will create their own estimation templates and it will be complete chaos in the end.
- Not including Risks impact in estimates – Identifying risks upfront, and calculating Risk Exposure will provide credibility to your estimates and will also help you during execution.
- Creating estimates that assume that no one will go to training, attend meeting, vacation, get sick, etc. – in any business, resource need to be continuously trained, people get sick, people goes on vacation, etc. So in your project plan, you should also compensate these factors otherwise you will face resource crunch during execution time.
Conclusion – So is it Art or Science?
Assumptions are always involved in any of the estimation technique you use. But it’s always better to start your estimation with any of the statistical estimation techniques based out of your historical data, and finally at the end, bring art factor and refine your estimations based on assumptions, risks, and other factors. So, to summarize following is common rule for Top Down and Bottom Up Estimations,
- If you are estimating on a project which has similar organizational historical data – you can rely primarily on science and apply art as a final step.
- If you are estimating a project that doesn’t have much organizational history – start with science, not exceeding your point of knowledge and organizational history, and then apply lot of art to come up with accurate estimate.
So estimation is always a combination of both – Art and Science, the key is how well you combine both. As your company’s or team’s maturity increases, you will see transition from art side of estimates to science side of estimates.
Happy Estimating !!
One thought on “Software Estimation – Is it Art or Science?”
[…] the previous post, we looked into different aspects of software […]