Software Estimation

Being able to effectively estimate a project’s scale is critical to ensuring success, particularly in a software development setting where those estimates support release planning and, of course, working out how many people are needed. However, the unavoidable uncertainties that surround all projects mean that producing an estimate that reflects all necessary complexities and possibilities is often very difficult.

In this post I’ll look at some of the specific ways in which traditional estimation techniques can lead to budgets spiralling out of control or products delivered being of a poorer-quality than expected, and introduce some of the techniques we use at Box UK to ensure that our estimation process facilitates the flexibility and understanding required to produce relevant and valuable software products.

Uncertainties affect estimation

Estimation is as much an art as it is a science, and this is especially true in a bespoke development environment where every organisation has its own unique needs, motivations and requirements against which the finished software product needs to deliver. Further complexity is added by the fact that requirements change as a project progresses; no matter how fixed initial ideas may seem.

As a result, the software development process has often been visualised as cone-shaped with the number of uncertainties being reduced as the project progresses towards completion, allowing teams to become ever more accurate about the costs/timescales involved. Unfortunately, this also suggests you can only be truly correct with your estimation once the project is complete (and of course, many organisations will no doubt have experienced seemingly never-ending projects that remain 90% complete for an indefinite amount of time; showing that although the cone represents the ideal progression of a project, things don’t always adhere to that plan!).

Cone of certainty

The ‘cone of certainty’

Traditional approaches

In the past, uncertainty has often been managed by fixing all requirements and estimates upfront. Now while getting a fixed project price and deadline may sound attractive, in practice the client often ends up paying in some other way. Either the team has to work very long hours to get the product out within the timeframe originally promised (resulting in it being potentially lower-quality than expected), or the extra work is delivered as change requests (which come at a cost).

In this model, clients are also committed to the exact specifications defined at the start of the project. This makes it very difficult (or expensive) to change direction as new requirements are uncovered or plans are changed, meaning you’re likely to end up with a finished product that doesn’t meet your needs as effectively as it could and therefore offers less value to your business.

A flexible approach

So, how can the estimation process be adapted to ensure your products maintain relevance and value in a world of uncertainty? The answer is that, rather than ignoring any potential for change, you build it into the process. Flip the cone around, so instead of planning way into the future (and making a lot of assumptions) your estimation facilitates the creation of a development plan focused on delivering small iterations of work that can then be reviewed and refined before progressing further.

Cone of uncertainty

The ‘cone of uncertainty!’

Software estimation at Box UK

This is the approach we follow at Box UK; as an Agile organisation we’ve embraced the flexibility offered by this iterative and incremental framework and built the techniques it advocates into our software estimation process. All features and tasks are estimated relative to one another and based on historical data where possible, then prioritised according to their value to the client. Not only does this increase transparency by allowing the client to easily see what they can get for their budget, but as every feature has a wide range of possible solutions (from very basic to fully integrated) it also helps them to make decisions as to what should be included.

Importantly, these priorities can be updated and reassigned as requirements change throughout the project, helping ensure that the final product responds to the client’s actual business needs, rather than simply what was assumed at the beginning of the project before all considerations had been fully explored.

Since implementing this estimation model at Box UK we’ve seen great results, especially when paired with the same collaborative approach that we employ across the rest of the project lifecycle. Before undertaking any work, our consultants discuss the objectives of the project with key stakeholders to define the most appropriate solution to achieve these goals. This helps mitigate any likely issues at the outset of the project and ensures that both client and development teams have a clear and shared understanding of the project’s goals and vision.

Additionally, we embrace a test and learn approach, particularly for large projects which may require the use of new tools and techniques. For example, before designing a fully functioning system we recommend developing an initial prototype to sound out the technologies and prove the concept. Not only does this confirm that we’re on the right track before significant resource is committed, it also provides a benchmark against which we can better judge the likely scale of the full project.


We’re always looking for ways to improve and refine how we work in order to deliver greatest value for our clients, and our software estimation process is no different. We’ve found that by facilitating flexibility, rather than rigidly sticking to an estimate that may quickly become out-of-date, we avoid the hidden costs and quality issues of traditional approaches while delivering a product that really helps our clients achieve their objectives.

Want to learn more about what an effective estimate looks like, how these estimates can be produced, and the role they play in successful project delivery? Check out our webinar “More than a number: making software estimates count”.

About the Author

Owen Phelps

As Box UK's Head of Development, Owen is responsible for evaluating technology choices for specific projects, to ensure that client objectives and expectations are consistently met and exceeded. He is particularly interested in development quality standards and continuous improvement, as well as the ways in which developers may maintain and improve their skills to ensure continuing relevance to the market.