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 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
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
Parametric model
Pert Model
Delphi Model
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.