The benefits of an Agile software development approach are well known. Agile invites change and refinement of scope throughout the lifecycle of a project to help organisations converge on the right product for clients. This is achieved through short iterations of development effort with frequent feedback during each iteration rather than a single big but often disappointing ‘ta-da’ at the end of the project. How then does Agile work in a fixed price contract where not only is price fixed but time and scope are fixed as well? Indeed, how do you estimate an Agile project to determine a realistic fixed price in the first place?

At first glance a fixed price contract implies a traditional waterfall approach, i.e. a tightly defined signed-off specification with no deviation on price, time or scope. This appears to be in tension with Agile which encourages change as an essential component of the process.  As we will see in this article it is possible to embrace change in a fixed price project by varying the scope.

To estimate a fixed price project in Agile you need to know the velocity of your Agile team in terms of story points, i.e how many user stories of what size and complexity the team can get through in a two week iteration or sprint. Estimates are measured in story points rather than in man hours. These are an arbitrary measure of the relatively size and complexity of user stories and are usually based on the Fibonacci sequence (1,2,3,5,8,13,21,34,55,89,144) or a Fibonacci-like sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) as this helps to emphasise the relative size and complexity of user stories in the product backlog. The bigger and more complex a user story, the higher the story points value. User stories are simply functional requirements expressed in terms that users and stakeholders in the business can understand for example – “As a Customer I can view and amend my online shopping basket.” This can then be broken down into smaller implementation tasks for a development team.

To estimate a project in terms of time you can use the formula:

Time = (total project story points / team velocity) * iteration length

So for example, if your team's velocity is 25 story points per two week iteration and the product backlog of user stories for the project has a total of 250 story points then we can estimate the time as:

Time = (250 / 25) * 2 = 20 weeks or 10 iterations or sprints.

Assuming a 7.5 hour day and a team of 5 and an hourly rate of £20 per hour we can estimate the cost of the project using the formula:

Cost = hours per iterations * number of iterations * people * hourly rate

So that …

Cost = 75 hours * 10 * 5 * £20 = £75,000

We have estimated the project will take 20 weeks and cost £75,000 so we are then in a better position to negotiate sensibly on the commercial aspects of the contract including any contingency and a margin for profit.

As the project progresses and changes emerge we can embrace this change in a number of ways. If the client changes their mind and wants another 20 story point user story added to the project then, because the project is fixed price and fixed time, this can only be achieved by removing another user story of equivalent story point value from the project.

Alternatively, where product backlog items can be given a MOSCOW priority then user stories prioritised as Shoulds and Coulds may be omitted if more time and effort is required for the Musts or new Musts are added due to new scope discovery during Sprints. In this way we can maintain the fixed price and deadline by adjusting scope. If all the product backlog items in the project are Musts and there is little room to manage scope in this way, then the client will need to make a difficult decision to remove Musts from scope risking viability of the product or they will need to agree to extend the project by the required number of iterations and provide additional funding.