Blog

Software Development Estimation Process

Introduction

When the client plans to develop a software the first question that bothers the company is the cost of the project and the time when the project can be delivered. The software development vendor is also concerned about the required effort and time needed for the project as that’s the foundation to negotiate the project cost and the basis for reasonable cooperation.

The estimation is a process of discovering the size of the software project effort in terms of time and resources for the final delivery expressed by money at the end. Software development is a complex process which requires extensive research and innovative solutions. Thus, making any presumptions regarding the time and materials required for engineering tasks is quite risky.  For a realistic estimate you should consider detailed specifications, design complexity, technology stack (the combination of programming languages, frameworks, and tools that will be used by the developers) as well as the personality factors as the skill level of each developer who will be assigned to the project are different. Besides, the time spent on making estimations (which approximately takes 10% of the engineers’ time) and extraordinary circumstances and unforeseen customers’ requests, challenges, and issues should be counted. Nevertheless, project estimates have their downsides and are not often as accurate as they seem. And besides the estimation challenges posted above, there are two other significant contributors to software estimation difficulty which are project unknowns (unclear and changing requirements) and project novelty. The sources of novelty can be innovative features that need extra research and emerging technologies that might sometimes be too young and immature. In fact, according to different sources, inaccurate estimation is cited as one of the top 10 reasons IT projects fail.

To make task estimation outcomes valuable and reliable, project managers should have a structured approach to managing the process of estimation and use good estimation techniques. In this article, we share some insights about the best practices applied in software development estimation and provide tips to avoid the risks inherent. 

 
software development estimation

Software Development Estimation Steps

The estimation process is usually comprised of the steps mentioned below. 

Step 1 Requirements Gathering

First comes the clarification of the desired outcomes. Even if the project’s scope can’t be properly defined and provided by clients in some cases that should be done by the software development company if the start of the relationship has already been built and this process is trusted to the vendor company. This is the most important phase of the estimation process as the software development company should find the needed information about the client and the project and define whether they can assist with the estimation and further development of the software. Particularly the business goals as well as the reasons for initiating the project should be identified. Must-have vs nice to have features should be agreed upon, and the preferences regarding the technology should be clarified. It’s also very important for the software development team to understand the target users and preferably the monetization model as well. Then stakeholders’ analysis should be made to define the people who will have authority in the decision making and what information should be provided and received from them.

Step 2 Decomposition

In this step the project team works on breaking down the high level requirements into smaller components which can be prioritized and\or grouped together. All the team members take part in this process to ensure that all the needed functionalities are listed. So the aim of this phase is to create measurable and manageable deliverables. While Agile methodologies present this as backlog with user stories and features, traditional methodologies and Waterfall model assumes creating the Work Breakdown Structure which is centered around creating visual hierarchical representation of project deliverables. 

Step 3 Provide estimations for each activity

In this stage the actual sizing of the effort is done. Agile estimations methods suggest relative estimating focusing on size and complexity level – this happens at the story level. When traditional project management framework is used the sizing is done by absolute estimating which focuses on ideal time – this happens at a task level.
Story points is a measure of the relative size and complexity of the story. It represents the size of effort of the user story and how the story compares to others on the backlog. The estimation by story points avoids the need and waste behind precise estimates. Story points rate the relative effort of work in a Fibonacci-like (modified) format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Ideal days presents the amount of time some work is likely to be taken by one person if they are not disrupted. If two people will work on it, their time is added. The estimation by ideal days is often expressed in days or hours.

Estimation Methods and techniques

 Top-down estimation method is based on expert judgment and is used to provide a rough estimation of major deliverables. This method is not preferable when the detailed estimation should be achieved as it doesn’t involve technical staff during the estimation process and may not be considered the capabilities of each developer.
Bottom-up method gives a more accurate estimation and is more reliable, however, is time-consuming. This approach involves all members working together to determine the necessary tasks to reach that final end product and every team member provides an estimate for his work.
The statistical method looks back at the data trying to guess the effort for the upcoming project. The drawback of this method is that historical data is not always a valid source because it can be biased and scanty.

 

Traditional (waterfall) Estimation Techniques

 Analogous estimating

This technique assumes searching for analogy in previously completed projects trying to find similar features and components. There are even some software applications that can help to identify such projects. So the estimation is arrived at by identifying a feature or component with similar complexity and judgment of the relative size of the feature.

Parametric model

 
Software managers sometimes use software parametric models to make an estimation. A software is a set of related mathematical equations that incorporates variable parameters. 
 

Pert Model

PERT is a “weighted” average estimate technique. It uses a formula to estimate the expected time of the project. It uses optimistic or shortest possible, pessimistic or longest excluding major catastrophes, and most likely weighted at 4 times:
                 PERT = (Optimistic + 4xMost Likely + Pessimistic):6
               

Delphi Model

A group of experts gather to work on estimation. They each provide their estimation unanimously, then they exchange views and the facilitator sums up the data.
 

Agile Estimation Techniques 

T-shirt Sizes

This techniques provides epic level estimation to the large backlog of relatively large items. Items are grouped to t-shirt sizes: XS, S, M, L, XL based on open and mutual collaborative discussion. 

Affinity Sizing

When this technique is used the team members raw a line on the wall and put the user story card on it from smallest to largest. Then all the other team members review the stories and silently put them up or down  on the wall relative to each other. At the end bucket values (points) are determined when everybody’s opinion is considered and so team decision is achieved.

Planning Poker

Planning poker is a consensus-based method of estimating efforts widely used for agile projects. Team members play and review each story by face-down cards on the table instead of speaking them aloud. At the end everyone shows their card with story points.

 

Complexity Buckets

The team agrees first on what buckets/criteria can add complexity. Then they review story through each bucket to determine how complex it is. At the end they combine the points from the buckets, then use consensus to decide final story point value to assign.

Step 4 Review and Analogy

Sometimes the software development team decides to use different techniques to have 3 figures as “best scenario”, “worst scenario”, and the “most likely scenario”. Or some teams prefer to provide the initial estimation version to experts to have their opinion or ask the peers from other teams to review and provide their perspectives. 

Step 5 Estimate Finalization

This is the phase when all the estimations are aggregated to have a baseline estimate. Then some risk buffers should be added depending on the project’s overall complexity to avoid common risks such as the unpredictability of new technologies, third party integrations, and of course time spent on team meetings, communication gaps and conflicts should be considered. In the end, the estimation should be validated by the management from a business perspective. 

Practical Tips for a Realistic Estimation

Rule 1: Time spent on planning, estimating and retrospectives should be considered. Usually 20 percent of the total time is spent on meetings.


Rule 2: Team velocity should not be compared with number of full time employees in the team. You should account that some work can be done simultaneously by team members and some have dependencies, besides the staff availability by hours cannot be the same. So when converting story points to hours and making estimation by man-days some adjustments should be done.
Velocity is a measure of a team’s rate of progress used to estimate future commitments/capacity. It is widely used in Scrum, XP, and other Agile frameworks and is achieved by summing the number of story points “Done” in an iteration/sprint. No partial points are allowed. Measured by summing the number of story points “Done” in an iteration/sprint. It’s not suggested to compare one team’s velocity to the other’s.


Rule 3: Estimations should be updated by time as the actual adjusted velocity figures can provide more accurate estimations for the final delivery.


Rule 4: Estimations should be provided by a range to avoid the risk of project unknowns and novelty as sometimes efforts on research cannot be predicted and extra unforeseen efforts may arise with emerging technologies.


Rule 5: Several estimation techniques should be used for having average data on the needed effort for the least probable and the most probable scenarios of the software development.
 

Final words

Accurate estimations are an essential part of the relationship-building between the client and the software development company and the basis for expectations management & trust-building. In the end, it would be right to consider that software estimation is an assumption based on experience and a disciplined approach for guessing the software development effort. But after all, changes should be anticipated as the final goal of the development team is the value that will be delivered and the quality of the software.
This guide can be used to understand the software development estimation process. We hope that the tips and tricks stated in this guide can be used to provide an accurate and realistic estimation and achieve the best partnerships.

We, at DevelopWay, initiate the estimation process, to understand the effort needed for the delivery of the needed software, irrespective of the documented need, if the customer has a clear understanding of the final product and is able to provide some of the business and technical requirements, say some functionalities, client profile, business model or app mockups, etc. Learn more about our services and contact us for a consultation.