Even before the planning stage, it’s wise to have a good forecast of the time and effort you will put into application development, how much your project will cost, and what you can expect from the development process.
Let’s familiarize ourselves with the software development project estimation concept, see why it’s essential, and how to avoid a planning fallacy that could ruin the end result.
1. What is software project estimation?
Long story short, software development estimation is a crucial process that revolves around predicting the project’s time and effort, cost, and scope; all this information is necessary for the planning stage and to ensure the project’s success. Additionally, it also takes into consideration, in terms of custom software development, the experience of the company you’re working with, their tech stack, and their own process they need to follow to finish the project (also known as the software development life cycle).
Even though an estimation is not the final software cost but just a ballpark range of the project – it’s essential to be as accurate as possible. To be transparent and fair, an estimate should take into consideration the following points but doesn’t have to be limited to them:
- Tasks – the details of what needs to be done
- Resources – what human resources are available
- Rate – cost to time ratio, the payment currency, and discounts
- Duration – how long will the project take to complete
- Third-party services – what additional services are necessary for completing the project
2. Why is software project estimation important?
The estimation accuracy is crucial because the client needs to feel confident that they can fund the project before committing to it. Also, there are many side effects of poor project estimates, like:
- Going over budget
- Cutting corners to avoid going over an unrealistic budget
- Running out of funds
- The developing team has low morale due to unrealistic expectations
… and those are just some examples. But you get the idea – the more accurate the software project estimations, the better the chances of successfully finishing the project. So, as a recommendation, the error margin should be anywhere in the range of 5 to 10 percent.
We’ve seen the effects of poor project estimates, but what about the benefits of estimation?
- They are usually a pre-requisite, so they must be done anyway
- They provide a common language and a bridge between the team and the organization the project is for.
- Estimates provide alignment across the project team, providing transparency and validating or questioning assumptions.
So what do you need to estimate a software project? Here is a list of inputs that you will need to be able to create a meaningful result:
1. Scope of work
a. User requirements – this is needed to understand the system’s complexity.
b. Non-functional requirements – an app that must remain available at all times will be built differently than an app that will only be used during office hours.
c. External factors – summarized as PESTLE (Political, Economic, Social, Technological, Legal, Environmental).
2. Project risks
A risk is something that has the potential to happen and, if it materializes, will cause a measurable impact on the project. Each risk can be prevented, reduced, accepted, or transferred.
3. Tech stack
a. Is there a requirement to write something of a legacy nature?
b. Are any items from the tech stack going to end of life during the project?
c. Is the tech stack aligned with the present competencies in the organization?
3. What are the types of estimation?
No matter the type of development estimation, there are a couple of questions that any software project manager should ask that aim at the most critical six constraints before starting the software project estimation process, such as:
- Scope of the project – How much work is to be estimated?
- Estimation technique – How to estimate the project?
- Schedule – How much time will it take to finish the project?
- Resources – Who will be working on the project?
- Cost – What is the required budget?
- Risks – What blocking points might appear?
Estimating software projects should have three major parts at the center: effort, cost, and resource predictions. There is more than one estimation technique. However, during the early stages of a project life cycle, when the product requirements are still fuzzy, and there isn’t much data to base the project estimation on, an initial estimate is made, all known as a “ballpark estimate.” Let’s see what types of estimation techniques you can use:
1. Parametric estimation
This type of estimation uses independent measurable variables from the actual project work. For instance, the effort needed to build a work packet will be calculated using the variable representing the lines of code in the project. The parametric model gives more accuracy to the estimation since it uses more of a statistical or mathematical approach.
- Step 1 – establish the factors of development (business or functional requirements, non-functional requirements, project complexity, tech stack, etc.)
- Step 2 – obtain information about the required work to complete one unit from similar projects completed in the past.
- Step 3 – the cost is predicted by using an empirical relationship between the factors from step 1 and the total units from the project.
2. Topdown estimation
This method is more beneficial for initial estimations. The project’s scope is reviewed at a high level and divided into features or estimated deliverables. However, this doesn’t include breaking down the project scope into smaller pieces of work.
Mainly used for projects in the initial stages, where there isn’t much information available. Less time-consuming than the bottom-up method, but it provides high-level estimations.
3. Bottomup estimation
This estimation model is useful when the requirements are known at a discrete level, where the smaller work pieces are aggregated into the whole project. As the name implies, this is the reverse method of topdown estimation.
The scope of the project needs to be described at a low level with all the details, and those components of work are estimated. The work breakdown structure can be used to present the detailed project scope.
The bottomup estimation is usually precise; however, it might not provide a buffer in case of scope changes. Therefore, it is recommended to use this type of estimation technique for more mature projects; it’s more time-consuming but provides a more precise estimation.
4. Threepoint estimating
This one uses a mathematical approach, the result being a weighted average or an optimistic, most likely, and pessimistic estimation of the work package. This is also known as Program Evaluation and Review Technique, or PERT.
Three ranges of estimates from three different data points are provided. Those three data points are “best scenario,” “worst scenario,” and “most likely scenario.” The pessimistic estimation considers negative risks that can happen, while the optimistic analysis includes positive risks. The final result is the weighted average of the estimates.
There are two methods of calculating the final estimate:
- Beta distribution – includes weight in the estimation formula
Estimation = (p + 4m +o) / 6, where
P= pessimistic, O= optimistic, M= most likely
- Triangular distribution
Estimation = (p + m + o) / 3, where
P= pessimistic, O- optimistic, M= most likely
This three-point estimate reduces the chance of having an inflated estimate. Additionally, it’s one of the most straightforward yet accurate project estimating techniques.
5. Planning poker
Mostly used in agile software development, the planning poker estimation approach is used to estimate project backlog. The name comes from the fact that the team uses cards while estimating.
Team members estimate all items in the backlog using cards; after the product owner describes the items, each team member thinks about the estimation and prepares the card. Simultaneously, everyone shows their cards, and the session ends when the team reaches a consensus.
Agile estimations are also used to estimate story points, even for virtual teams. This estimation technique’s apparent benefit is that all team members think about the estimation simultaneously. This way, nobody is being influenced.
6. Expert judgment
As the name suggests, this method involves experts in the project estimation process since they have experience with similar projects and can provide more accurate cost estimates. Additionally, experts will be integrating risk into their calculations.
4. Agile vs Traditional estimation
“Responding to change over following a plan” is one of the critical principles of the agile manifesto. This implies that agile estimation techniques will focus on what can be delivered over a short-term period rather than a long-term one, with the waterfall model.
Agile software estimations are often lightweight, vs traditional ones that require pages and pages of documentation before being submitted, therefore being less time-consuming.
It’s interesting to note that some development teams argue that estimations are unnecessary, wasting time that would be better spent on delivery. Their approach is to split all deliverables into similarly-sized subtasks and keep a constant delivery flow. #NoEstimates
5. What are the four basic steps in software project estimation?
Generally, there are four basic steps in software project estimation:
1. Estimating the project size
This will usually end up either in Lines of Code (LOC) or Function Points (FP). The sources of information for this step should start with formal descriptions of the requirements. This step can be completed either by analogy or by counting product features and using an algorithmic approach to convert the count into an estimate of size.
2. Estimating the effort in person-months or person-hours
You can convert the software project size estimation to the total project effort only if you have a defined software development life cycle and a development process that you must follow. This effort estimation requires you to identify and predict all the necessary activities to build the product. You can do this either by using historical data or with an algorithmic approach, such as the COCOMO model or the Putnam Methodology.
3. Estimate the schedule in calendar months
This can be determined by using the effort estimate. It involves predicting the number of people working on the project, what they will work on, when they will start working on it, and when they will finish. Again, like before, historical data help lay this information out in a calendar format.
4. Estimate the project cost
There are a lot of factors that can influence the cost estimate. For example, to determine the labor cost, the easiest method is multiplying the project’s effort estimate in hours by a general labor rate. However, you can get a more accurate estimate by using specific labor rates for each staff position in your team.
6. Why is software estimation so hard?
Until recently (around 2011), most development teams used the Waterfall model to plan projects. This implies that all the software requirements had to be defined upfront. However, the shift has been made towards Agile development. This means that the product is shaped through constant stakeholder conversations. What is finally delivered might not be precisely what was discussed in the initial concept. While Agile proved to be valuable when it comes to development, it has complicated things when it comes to estimations.
To make things easier, we’ve put together a guide that helps you with one stage of the software project estimation process: how much app development costs. We’ve used our own experience and comprehensive research and put together a guide with a working sheet that you can use.
