How to Accurately Estimate Software Development Costs

by David Burkett, Sep 30, 2016

When deciding to outsource software development one of the key concerns of potential customers will be how much the software will cost. If there is little detail about the requirements, then a chicken and egg problem begins because it is impossible to accurately quote on a build if you don't know what the build is. Most software development companies get around this problem by simply taking the cost of the largest build they have done previously and multiplying it by 3. This - in theory - leaves enough wiggle room for scope creep and some profit. But this is not our recommended practice!

The overall effect on the software industry for this type of costing is negative. Projects fail due to inadequate scoping, or software is built below par because the software development vendor does not truly understand their craft. 

"If you can't describe what you are doing as a process, you don't know what you're doing." - W. Edwards Deming

I believe that we must commit to more design and scoping up front to negate this problem. In fact, I believe we must go one step further and make sure all the scoping documents that are produced are meaningful to software bots so that they can efficiently write code alongside the human software developers.


In the Scope stage, we explore the problem or opportunity and propose a solution. We move in sequence through discovery, inspiration, ideation, and realisation stages. The project plan diverges at the beginning at the discovery phase into separate pieces, and then converges at the realisation stage.

Deliverables emerge from applying the Discovery Kit, diverging through steps, and then converging. This process of divergence can be found in the Scope diagram.
The Discovery kit is a powerful tool for ensuring an effective knowledge transfer, as well as being an effective lens for exploring ideas and preconceived notions.

Several important artefacts are created during the Scope stage, including a backlog of requirements, UX/UI designs, and a schema.

The backlog of requirements is particularly important. This is because custom software projects are typically priced on requirements.

There are many ways for project owners to express the intent of their software. Typically to describe the software, they verbalise it in meetings, document it via an email, draw some diagrams on a whiteboard, etc--there are lots of other hybrid approaches too like spreadsheets and tables. The aim of these strategies is to achieve a shared understanding of what needs to be built.

Capturing these requirements accurately is important for minimising the risk of flawed iteration estimates. However, it cannot eliminate the risk completely. Our strategy for capturing these requirements is to understand the user intent through Epics and User Stories. These are created and maintained within the Codebots project.

An epic is a description of a coarse-grained requirement in a story form. It may represent a theme, which can be used to categorise a bunch of related User Stories. An epic may look something like:

As a [type of user] I want to [do some action] so that [reason for action] 

A user story is a description of a fine-grained requirement. Each user story belongs to exactly one epic, where the user story is a subset of the feature defined by the epic. A user story is the unit of delivery for Iterations, so by definition a user story must be sufficiently small to deliver in a single Iteration. A user story may look something like:

As a [type of user] like [persona] at [environment]. I want to [do something] using [device] so that [reason for task]. This will [user goal].

Once epics and user stories have been captured, we can make estimations.

WorkingMouse staff each estimate the time units they believe are required for a regular staff member to complete a user story and epic. 

Our time estimation follows a precise, exponential scale:
  • 1 hour (0.13 days*)
  • 2 hours (0.26 days*)
  • 4 hours (0.52 days*)
  • 8 hours (1.05 days*)
This system enables WorkingMouse to more accurately capture realistic estimations of the cost of developing software.

Agile Processes

From here the estimate can become more accurate if the developers work with an Agile methodology. Breaking down the pricing into sprints allows for costing to be assessed per iteration rather than a rough overall figure.

Traditionally, companies work with one big plan which they create by developing a strategy, operation and tactic from the start. They come up with a list of requirements for this plan, evaluate how long the project will take and then provide a cost estimate. The downside to this strategy is that the feedback and learning process then can't come until the end of development.

One example of this is the massive blowout that happened concerning the government contract with IBM to develop a health payroll system. The project was contracted to IBM in 2007 but was plagued by delays and budget blowouts. When the release finally happened the system failed, resulting in a complete scrapping of the project. However, IBM was still wanting the full payment of around $1.2 billion. This failure can be linked to developing without effective scoping.

Working in iterations allows you to build to achieve smaller targets. At the end of each target you can obtain valuable feedback to assess if you are still working towards the right project goals. This provides huge costs savings because you can pick up changes that need to be made to requirements at a much earlier stage in the build. This prevents situations, like the health payroll system, where customers are not aware of issues until the final product is released and the final payment is due. For example, if you have a plan to develop a project in 3 sprints and through feedback identified changes to the requirements after the first iteration, then you could save on the final two thirds of the cost by picking up on the issue earlier. For this reason the agile methodology can help to give a far more accurate final project estimate.

Developer Costs

After identifying the costs of each iteration, a business should then work out how many developers will be needed to achieve each sprint. This figure is then used in combination with the cost of the sprints and multiplied out. However, this is the part of the process that can often blow up the overall project cost. Generally in Australia the average software developer salary is over $83 000 per year. Additionally, software architects and senior developers can earn on average over $120 000 and up to $176 000 per year. These figures can persuade businesses to turn to offshore software development.

Offshore software outsourcing can appear a much cheaper alternative because of the lower wages afforded to overseas developers in countries like India. However, offshore outsourcing comes with a variety of long term risks and may involve unexpected costs such as legal fees or additional training costs. In fact one of our previous articles about the ‘20 risks associated with outsourcing offshore' noted that figures suggest the final sum up of offshore development can leave expenditure up to 65% higher than estimated.

Alternatively, WorkingMouse has developed a solution to lower the costs associated with paying for developers onshore. Our software bots are able to generate more than 90% of our code, which significantly reduces the workload of our developers and testers. The result of this is that a project will require a much smaller number of developers and testers to build it. In turn this will help reduce the overall project cost for clients.

Using these three strategies to refine the costing process for building software will greatly help towards achieving a more accurate estimate. Reducing unexpected costs can in turn help maintain a better customer satisfaction level and so is beneficial to both the software developers and customers. More importantly though, implementing a thorough scoping process will lead to a higher chance of creating successful software.

If you want to read more on outsourcing, check out David's article on how you can protect your IP when outsourcing in India