Software project effort estimation – the agile way

Estimating the effort needed to complete a certain software project is incredibly difficult. At the same time it is important to have some indication of development effort in order to estimate cost and decide whether to do the project. We shared four estimation methods with our students in our software project management course, and have some practical advice to make these methods work in practice.

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

Methods for effort estimation

Effort estimation is in essence a simple problem. Before embarking on a software project, clients want to do know what will be built and what it will cost. In previous blog posts, we described how to define what will be built: via a project vision, a functional scope in user stories, and non-functional requirements. In an ideal world, one would combine all these elements, apply an effort estimation method to calculate a development effort and cost. According to the text books, there are four effort estimation methods: expert estimation, top down estimation, bottom up estimation and parametric estimation.

How the methods work in practice

The truth is, none of these methods work really well. All of these methods have a huge margin of error when used at the beginning of the project. This is true for the simple methods (expert estimation, top down estimation) and the complicated and time consuming methods (bottom up estimation and parametric estimation). The best available formal method is Function Point Analysis. It is a good method because it is well defined, structured, repeatable and objective. Even this method cannot magically remove the uncertainty of projects. If FPA indicates that the effort is 1000 hours, one only knows that the effort is somewhere between 250 and 4000 hours. More precise insight is only available if one starts the project: each iteration one gets more experience what the team can do and what the customer needs. We use the cone of uncertainty to illustrate this concept. As you can see, only at the end is effort completely known.

How to deliver on time and budget

The reason project sponsors want estimates, is that they want projects to deliver on time and on budget. There are some techniques for doing this. The first step is indeed to flip the question around: rather than searching for perfect estimation methods, search for techniques that help projects deliver on time and on budget.

We believe that the agile approach and principles have the most practical advice for this. If you want to deliver a software project on budget and on time, you have to make the scope flexible and deliver in multiple iterations. You should make an initial effort estimate in order to apply for resources, but you should assume that this estimate is wrong. You should make sure your scope is flexible in two ways. The functional scope should be defined in multiple, independent user stories. The non-functional scope should be made flexible by defining multiple levels. In your project plan you should make multiple iterations and releases and make sure that the most urgent/valuable user stories are delivered first. This way, it is assured that the users get their most urgent need far before the project deadline.

If your estimate was too optimistic, you will run out of time and budget before finishing the entire scope. If you managed the project well, you have already delivered several iterations of working software, containing the most important features. You should prepare a report for the project sponsor with two options: either stop the project with the results so far (on time and on budget), or start a new project phase for the remaining features.

Note that these two principles can also be applied if one does not want a completely agile approach. The image below shows a waterfall based approach with flexible scope and multiple iterations.

How and when to estimate

As you can see from the previous paragraph we recommend making some kind of initial effort estimate in order to get a first insight into required budget. It is important to make a first estimate, but keep it light and simple. Do not spend too much effort on this: the estimate will be wrong anyway. It is best to not treat it as a reliable number.

The good thing is, you can get better estimates later on in the project. As the project progresses, you should update your estimate based on the actual progress. Ideally you should have short sprints where you deliver complete user stories. You can compute how much hours per user story are needed on average. Using this average you can get a new, better effort estimate for the remaining user stories.

If you want more precision, you should not just use a single average per user story, but try to size the user stories in some way. This can be done by hand (sorting in three buckets small, medium, large) or using story points or function points. Either way, your estimate will get better every sprint because you will have better data. The quality of the data is the most important factor in getting a better estimate.

Next steps

Next to this high level blog, we also created a more detailed blog on the four methods for software project estimation. For the last method, the parametric method, we described cosmic function points. We hope you find this series useful and are looking forward to suggested additions or suggestions. Please email one of the authors if you have any comments or questions.

Image credit: Hindrik Sijens  (weights) CC