Close

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

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

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.

Conclusion

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.

We’d love to hear your thoughts on the estimation process – where are the biggest uncertainties for you? If you’ve experienced issues in the past, how have you resolved them? Please leave your comments below, or get in touch today to find out more about our processes.

About the author

Owen Phelps

Owen Phelps

Owen is a Software Architect at Box UK, working closely with the development team to ensure requirements are meet and client expectations exceeded. With nearly 20 years’ experience in the industry, Owen particularly enjoys keeping up to date with current trends and evaluating the latest software technologies.

Comments

James Saye

Apr 25th, 2013

Great post. I always enjoy reading the blogs here. Firstly, there must be quite a lot of requirements that need to be set at the start of the project so what proportion do you think are set at the start? And do you agree that a good requirements capture process could help with requirements change later in the project?

Owen Phelps

May 16th, 2013

Hi James. Thanks for taking the time to respond. Regarding how much is set at the start, I like to distinguish between business requirements and design requirements. A lot of “requirements” are really design decisions in disguise. In my experience, the design requirements are the ones that are going to vary lots of the course of the development. The business requirements will change too, of course they will, but not at the same rate (assuming of course, you’ve done a reasonable job extracting them in the first place). So, yes, a good capture process will help in that it will establish the less volatile business requirements. The trick is to recognise the design requirements for what they are, and anticipate and manage their evolution.

David Grant

Jun 10th, 2013

In your post you mention that you use relative sizing for both features and tasks. The use of relative points for estimating features is now a widely-accepted practice, and some teams even choose to burn-down using those relative points to reflect progress during an iteration. What benefits are your teams seeing by using relative estimating for tasks?

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Add Your Comment

Related content

We're hiring. Let's talk. View available roles