How to Estimate Software Development Project

Estimating the project costs is a must-do procedure for every IT project, no matter how big it is. McKinsey’s report conducted several years ago claims that over 66% of projects overrun costs – a third of them go beyond the estimated schedule, and about 20% fall short of promised benefits. One of the main software project estimation goals is to reduce this percentage.

If you have some experience in employing development services, you may know that the software development cost might change under the customizations made or corrections added to the documentation. The final budget might as well grow into something you considered unfeasible initially.

To have good command in analyzing the software products’ pricing and answer the question: “How to estimate app development project?”, we strongly recommend to check out the following article.

Why Do We Need Software Estimation?

A software cost estimation is a great opportunity for both the provider and the client to discover if the final result will be feasible and how much value it will bring. But software estimation is not an easy task, and if you try to take the same approach to different projects you will probably fail. And there are lots of reasons why every project requires a unique approach.

Be responsible for evaluating the project, because the success of what you participate in will depend on taking into account all the nuances in the early stages. Even when ones might think they won’t underestimate, they will still do anyway.

It doesn’t matter what area of life we take, people have an inherent bias to underestimate, which is called “the planning fallacy”. Of course, this is not applicable to everyone, but be cautious starting a new project. 

At the same time, while it is important to minimize the impact of the fallacy, it is no less important to understand the problem of overestimating the development time. Striving to avoid the scenario where something was promised but not developed, people often try to stretch estimates to allow for any unforeseen delays.

Don’t you agree that it would be better to under-promise and over-deliver than to over-promise and under-deliver?

Another common problem in the estimation process is Parkinson’s law which states that “work expands to fill the time available for its completion.” This means that no matter how much you increase the time for product development, there will always be tasks to do in the process. People start stretching tasks out, which affects productivity.

Reasons Why it is so Difficult to Estimate Accurately

As we’ve already mentioned, there is no one-size-fits-all solution for all projects. Software development costing is a dynamic process as new technologies, new approaches, and methodologies appear. All of this greatly impacts the estimate.

Another quite relevant question is “Why is it so difficult to estimate software accurately?”

Jelvix experts are sure that those who are responsible for estimates rarely take into account lots of small nuances, such as the team members’ productivity and experience level, vacations, sick leaves, unforeseen defects during the implementation stage and customer requests, troubleshooting, team ramp-up, administrative issues, and so on. All these points may seem not too important, but each one of them can result in an inaccurate estimate.

For a more accurate estimate of the project time, many advise to split  large tasks into subtasks and think in advance about collecting requirements, documentation, mock-ups, prototypes, UML diagrams, etc. This method has a right to live, but it is the complete opposite of agile methodologies.

The main problem here is that the likelihood of changes in the requirements is quite high as soon as people start using the product being in the pre-release state. In this case, all the preliminary work can be a waste of time.

Another point is that requirements change mid-development as well. Thus, you will need additional tasking and estimation, but doing so be sure that you have reflected them in the initial estimate.

Also, estimates are often not updated when the team realizes they have already completed the task. It is a fairly common situation when developers speed up their work or work longer and on weekends. In the case of speeding up, the team members’ performance does not increase, and this can decrease the quality and increase the risk of missing requirements.

The second method is a sure way to burnout, which will inevitably lead to a decrease in productivity due to overwork and inability to maintain the overall pace of work.

The Importance of Project Estimation

Estimates provide value to both clients and providers, and here are some benefits both sides can get:

Approach to Estimate a Software Project

In this section, the Jelvix experts, who have more than 10-years’ experience in estimating software products in various domains and of different complexity, would like to share some ideas on how to organize the fluent and smooth process of the software project estimation.

Define a Project’s Complexity

Before starting any works, define your project’s complexity to understand the team capacity, risks that can influence the project’s duration, a best-fit methodology to use. Due to the possibility of such risks, it is important to add 15–20% on top of your project estimation. We recommend to divide each project into three types:

Make Rough Estimates

Before you start working on a project, the client may ask you to provide them with a forecast of the duration of the project to form expectations and understand if the allocated budget will be sufficient.

Our experts have been estimating projects of various complexity levels for many years, so they highly recommend giving such an estimate already in the proposal document – where you describe your vision of the project and provide your version of solving the customer’s business issue. 

Also, if your company has a business analyst on staff, be sure to bring in one to help assess the requirements.

Prepare the Scope of Work

For the software cost estimation, a good idea would be to prepare the scope of work that covers all defined software requirements and then assess each requirement. Remember to consider the software development methodology you are going to use for your project.

Add a Risk Buffer

Add a risk buffer of up to 20% of the overall project time to avoid common risks, such as issues that are hard to foresee, new technologies you will have to implement, miscommunications inside a team, etc. The percentage depends on the project’s complexity level. Remember that it is always better to under-promise and over-deliver than to over-promise and under-deliver.

Consider “Time Eaters”

Add at least 20% of a project’s time to cover various “time eaters”. According to the “Manage the Unmanageable” book by Mickey W. Mantle and Ron Lichty, the project team only spends 55% of the time actively developing. Talking with PMs and colleagues, reviewing the code, research, etc. take up the remaining 45%.

Predict the Team Capacity

After you have identified all team members, create a table that displays their roles, responsibilities, estimated time they are going to spend on their part of the project, etc. For example, you can use something similar to this table:

Of course, there is no need to specify 40 hours per week for each team member because they may not be engaged in the project development on a full-time basis. And even if they are, there may be a lot of associated tasks, such as additional research, e-mailing, meetings, etc.

In a “Primary Contribution” column, include the main responsibility of each defined team member. This will help you track the areas of engagement of each of the specialists.

Write User Stories

To make the estimation more precise, plan the overall project scope. User stories give the development team a vision of how a certain product should work and look like. They also allow clients to ensure that they are on the same page with the team. In our article, we described best practices and gave some examples of how to write user stories and acceptance criteria.

Define Story Points to the Tasks

A nice way to assign story points to the tasks you are going to perform is to use the planning poker.

1. Give a set of “poker” cards to each team member with values of 1, 2, 3, 5, 8, 13, 20, 40, and 100 story points.
2. Name the task, for example, “Creating mock-ups for the item ordering procedure”. Let each team member choose one card. The number on a card equals a number of steps to perform to complete the task. Then, let team members explain why they have chosen particularly that number for story points. Agree on each of the discussed tasks.

There is one important thing for proper planning with the help of planning poker: only those who are responsible for completing tasks can vote for story points. This is necessary to get the most objective results, taking into account all the nuances that only those who have already performed such tasks can know about.

Determine the Team’s Velocity

After you finished with user stories, the next thing you should do is to break each story down into a series of tasks, each one having an estimate. We recommend having no more than 4 hours estimated to perform the task, no matter how complex it is.

The individual work speed matters a lot. People who estimate often are not a part of the team who will work on a product. To avoid misjudgment, a good idea is to base the estimation for each task on the average speed of the mid-level developer or whoever in another team.

Here is an example you may use to calculate the required hours:

Calculate the Project Duration

Last but not least is to combine all the knowledge you have gained and to split the whole project into sprints.

Gathering the findings of the steps from above, you’ll get the formula:

Duration of the project = overall task time estimation (E) + E*risk buffer + E*time eaters.

So, if a project’s overall task time estimation is 8,000 hours, the total project duration will be:

8,000 + 8,000*0.25 + 8,000*0.20 = 11,600 hours.

Project Estimation Methodologies

Waterfall Methodologies

You can estimate the time spent on product development using decomposition – breaking down system requirements into smaller subtasks. This is necessary so that you can see what stages each task consists of, and be able to more accurately determine the time for it.

Jelvix experts recommend using a tree structure – it helps to visualize all stages of development and associate them with the corresponding subtasks.

As examples, you can use the following methods:

• Analogy: an assessment based on similar projects with similar objectives. It is important to consider the planned and actual time spent on previous projects here, and if you see large discrepancies, it will be easier for you to understand the risk areas in your new project. You should pay extra attention to these areas in your new project.
• Wideband Delphi: a method similar to planning poker, but on a project-wide basis. It is based on the assessments of the entire team, comparing the results, and choosing the best grade for each requirement.

Note that you provide precise estimation for small and medium projects. For large ones, this is not always possible and the estimate may not be so accurate, especially if the customer makes adjustments to the requirements in the process.

For such projects, it will be sufficient to indicate the boundary values (optimistic/pessimistic). But in this case, the difference between values should not be more than 20%.

Agile Methodologies

Agile methodology means changes in the scope of work due to changes in requirements. The scope of all tasks is divided into sprints, every sprint lasts 2–4 weeks. It makes sense to start the process with the development of MVP. 

If you are going to develop products according to this methodology, we recommend evaluating the team’s efforts instead of the time spent. To measure the effort, you can use story points. For this purpose, poker planning sessions will be a useful tool.

In real life, it works like this: if there are 2 story points for one task, and the team needs 48 hours to complete it, 1 story point is equal to 24 hours. Having, for example, 600 story points, you can multiply that by 24 hours to get an approximate project estimate of about 14,400 hours.

Remember that an estimate is always flexible. In Agile methodology, it is important to evaluate every sprint. When needed, engage the client to suggest new features. Of course, always update your estimates after you come up with any changes or new ideas.

By the way, the Jelvix experts have made an extended material about these methodologies and their differences so you could dive deeper and choose which option is the best fit for your project.

Useful Tools to Track Estimation

Today the market offers many free and paid tools to solve almost any project management problem. We propose you a list of the most common ones, but which one to use is up to you. If you haven’t found the most suitable tool yet, try a few of them on small projects – this will make it easier for you to make a decision later.

• Jira – provides multiple features and functions, and is flexible enough for your project needs. There are many add-ons and extensions for the tool that will cover almost any project need.
• Trello – useful collaboration tool for project management and task tracking. The tool is a board with tickets, it is extremely simple to use and gives you a clear understanding of task statuses, assignees, progress, etc.
• Asana – a tool with unicorns for both small and large teams. The tool has its cloud-based features that allow organizing all the details of your work in one place.
• Google Sheets and MS Excel – widely used tools. They are good for calculation purposes and are more familiar to users.

Conclusion

Probably, you will have to update the estimates for separate tasks or the entire project because you might not have taken into account some of the nuances at the preparation stage. This is mainly because you might not have addressed all requirements in full. The more details you get from the client, the more accurately you can plan the work without making significant changes.

Constant communication with the client, informing about the progress of work, and feedback from the client are the main factors influencing the success of the project. Close contact will allow you to react as quickly as possible to any changes, and painlessly reallocate resources within the team.

In case you were looking for a team that would accomplish any given task in the shortest terms with high quality and reasonable price, you should check out the Jelvix guys! We have developed a bunch of dozens of projects for mobile and web platforms and successfully delivered them using our premium approach. 

When you need the software development project estimation, don’t hesitate to contact us – we will provide you the most precise budget options to create, deploy, and continuously support your product.