The Agile fixed price is a contractual model agreed upon by suppliers and customers of IT projects that develop software using Agile methods. The model introduces an initial concept & scoping phase after which budget, due date, and the way of steering the scope within the framework is agreed upon. This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance.

Fixed price contracts are evil – this is what can often be heard from agilest. On the other hand, those contracts are reality which many agile teams have to face. But what if we try to embrace and manage it instead of fighting against it? How can a company execute this kind of contract using agile practices to achieve better results with lower risk? This article will try to answer those questions.

Fixed Price, Time and Scope

Fixed price contracts freeze three project factors at once – money, time and scope – but this should not be a problem for agile teams. In fact, time boxing is common agile practice. Limiting money simply makes time boxing work better.

A real problem with fixed price contracts is the scope, which is fixed in terms of what should exactly be built instead of how much should we build.

Why are clients so obsessed with fixing the scope? We understand that they want to know how much they will pay (who does not want to know that) and when they will get the product. The only thing they don’t know, even if they will not always admit it, is what exactly they want as the final product.

The reason for fixing the scope has its roots in:

• Lack of trust between the contractors.
• Lack of understanding about how the agile software development methodology and processes work.
• Misunderstanding what the scope means.

Every fixed price contract has a companion document, the “Requirements Specification” or something similar. Most of the time, working in an Agile way, the business requirements are relatively light weight criptic notes captured on stickies or story boards and not in comprehensive Business Requirement Documents (BRDs) pre-approved by business before developemnt commences. Documented requirements tries to reduce the risk of forgetting something important and tries to set a common understanding of what should be done to provide an illusion of predictability of what the business actually wants and needs in the final product.

Key wrong assumptions in fixing the scope are:

• The more detail we include in the requirements and scope definition up front, the better we understand each other.
• Well-defined scope will prevent changes.
• A fixed scope is needed to better estimate price and time.

Converting the Fixed Scope into Fixed Budget

In understanding that the main conflict between application of an agile mindset and a fixed price contract lies in the fixed scope, we can now focus on converting the fixed scope into the fixed budget.

A well defined scope is done by capturing business requirements in as many user stories instead of providing a detailed specification of requirements. These stories are built into a product backlog. The effort required to deliver each story is estimated using one of many story point techniques, like planning poker.

It is key to understand that a higher level of detail in software requirements specifications, means two completely different things for both parties within a contract. Software companies (vendors / supplier), responsible for developing applications, will usually focus on technical details while the company using the software (buying party / customer) is more user focussed and business outcome oriented.

In compiling specifications four key aspects are in play:

• User stories is a way of expressing requirements, understandable for both suppliers and customers. The understanding builds trust and a sense of common vision. User stories are quick to write and quick to destroy, especially written on an index card. They are also feature oriented, so they can provide a good view on the real scope of a project, and we can compare them with each other in terms of size or effort.
• Acceptance Ctiteria, captured for each user story, are a formalised list of requirements that ensires a user story is completed with all scenarios taken into account – it specifies the conditions under which a story is fulfilled.
• Story points as a way of estimating stories, are units of measure for expressing an estimate of the overall effort required to fully implement a user story or other pieces of work on the product backlog. The team will access the effort to deliver a story against the acceptance criteria and in relation to other stories. Various proven estimation techniques can be adopted by the team for example effort can be expressed as a T-shirt size (i.e. Large, Medium, Small). To quantify the effort, each T-shirt size can be assigned a number of story points i.e. Large = 15 storypoints, Medium 5 storypoints and Small = 2 story points. (See also the section on Estimation below). The intention of using story points, instead of man hours, is to lower the risk of underestimating the scope because, story points in their nature are relative and focused on the whole scope or on a group of stories, while traditional estimation (usually done in man-hours) tries to analyse each product feature in isolation.
• Definition of done is another way of building trust and common understanding about the process and all the future plans for the project. It’s usually the first time clients see user stories and while they may like the way the stories are written, it may not be so obvious what it means to implement a story. Development teams who confirm with the client their definition of done, in conjunction with the acceptance criteria with, illustrate that they know better what the client’s expectations are.Development on a story will be completed when the defenition of done is achieved. This supports better estimation. In addition on the client side, the definition of done, in conjunction with the accpetance criteria, sets the criteria for user story acceptance.

Using the above four aspects, will provide the building blocks to define the scope budget in story points. This story point budget and not the stories behind it, is the first thing that should be fixed in the contract.

This sets the stage for change.

While we have the scope budget fixed (in terms of story points) we still want to embrace change, the agile way. As we are progressing with the project delivery, and especially during backlog refinement, we have the tools (user stories and points) which we can use to compare one requirement with another. This allows us to refine stories and change requirements along the way within a defined story point budget limit. And if we can stay within that limit, we can also stay within the fixed price and time.

Before Estimation

The hardest part in preparing a fixed price contract is to define the price and schedule that will be fixed based on, in most cases, not so well-defined requirements but preferably a well defined scope.

How can you prepare the project team (customer & supplier) to provide the best possible initial estimation?

Educate: Meet with your client and describe the way you’re going to work. We need to tell what the stories are all about, how we are going to estimate them and what is the definition of done. We might even need to do that earlier, when preparing an offer for the client’s Request For Proposal (RFP). Explain the agile delivery mothodology and you will use it to derive the proposal.

Capture user stories: This can be arranged as a time-boxed sessions, usually not taking no more than 1 or 2 days. This is long enough to find most of the stories forming the product vision without falling into feature creep. At this point it is also very important to discuss the definition of done, acceptance criteria for stories, iterations and releases with the client.

We need to know:

• The environment in which stories should be tested (like the number of browsers or mobile platforms, or operating systems)
• What kind of documentation is required
• Where should finished stories be deployed so that the client can take a look at them
• What should the client do (i.e. take part in a demo session)
• How often do we meet and who participates
• etc.

This and probably many more project specific factors will affect the estimation and will set a common understanding about the expectations and quality on both sides. They will also make the estimation less optimistic as it often happens when only the technical aspects of story implementation are considered by the team.

Estimation

Having discussed with the client a set of stories and a definition of done, we can now start the estimation. This is a quite well-known part of the process. The most important activity here is to engage as many future team members as possible so that the estimation is done collectively. Techniques like planning poker are known to lower the risk of underestimation because of some particular team member’s point of view, especially if this team member is also the most experienced-one, which is usually the case when estimations are done be one person. It is also important that the stories are estimated by the people who will actually implement the system.

Apart from T-shirt sizes to expressed effort estiamtion, as mentioned under Story Points above, the Fibonacci-like scale (1, 2, 3, 5, 8, 13, 20, 40, 100) comes in handy for estimating stories in points. Relative estimation starts with finding a set of easiest or smallest stories. They will get 1 or 2 points as a base level for further estimation.

In fact during the initial estimation it is often hard to estimate stories using the lowest values like 1 or 2. The point is, the higher the estimation, the less we know about the story. This is also why estimating in points is easier at this early stage, because it is far easier to tell that a story A is 2x as complicated as story B than to tell that story A will take 25 man-hours to get it Done (remember the definition of done?) and the story B will take 54 hours.

This works well even if we choose 3 or 5 point stories as the base level and if we do that, then it will be easier to break them down into smaller stories later during the development phase. Beware however the stories of 20, 40 or 100 points. This kind of estimation suggests that we know nothing about what is to be implemented, so it should be discussed with the client here and now in a little more detail instead of just happily putting it in the contract.

The result of the estimation is a total number of story points describing the initial scope for a product to be built. This is the number that should be fixed in terms of scope for the contract, not the particular stories themselves.

Deriving the Price and Time

Total number of points estimated based on the initial set of stories does not give us the price and time directly. To translate story points into commercial monetory numbers we need to know more about the development team’s makeup described in the number of differently skilled resources within a team, and the team’s ability to delivery work which is expresessed in an agile KPI referred to as the Team Capacity and/or Velocity.

The team’s velocity refers to the pace, expressed in story points per development cycle or sprint, at which a team can deliver work. The team’s capacity is defined by the average number of story points the team can deliver within a development cycle or sprint. An increase in the velocity, as a result of increased efficiency and higher productivity, will over time increase the teams capacity. Understandably, changing the makeup of the team will impact the team’s velocity/capacity. The team’s capacity and velocity is established through experience on previous projects the team delivered. A mature agile team is characterised by a stable and predictable velocity/capacity.

Let’s use a simple example to demonstrate how the team makeup and velocity are used to determine the project cost and time.

Assume we have:

• Estimated our stories for a total of 300 story points.
• The team makeup consists of 5 resources – 3 developers, 1 tester and a team leader.
• Agile Scrum will be team’s delivery methodology.
• Experience has shown this teams capacity / velocity is 30 story points over development cycle or sprint length of 2 weeks.

Determine the predicted Timeline

Time = <Points> / <Velocity> * <Sprint length>

Thus…

Time = 300 / 30 * 2 = 20 weeks (or 10 sprints)

Many factors during the project may affect the velocity, however if the team we’re working with is not new, and the project we’re doing is not a great unknown for us, then this number might be actually given based on some evidence and observations of the past.

Now we may be facing one of the two constraints that the client could want to impose on us in the contract:

• The client wants the software as fast as we can do it (and preferably even faster)
• The client wants as much as we can do by the date X (which is our business deadline)

If the calculated time is not acceptable then the only factor we can change is the team’s velocity. To do that we need to change the teams makeup and extend the team, however this is not working in a linear way i.e. doubling the team size will nor necessarily double its velocity but it should increase the velocity as the team should be able to do more work within a development cycle.

Determine the predicted Price

Calculating the price is based on the makeup of the team and the assocaited resource/skill set rate card (cost per hour).

The teams cost per sprint is calculated by the % of time or number of hours each reasurce will spend on the project within a sprint.

For our eaxmple, let assume:

• A Sprint duration of 2 weeks has 10 working days and working 8 hours per day = 80h per sprint.
• Developer 1 will work 100% on the project at a rate of £100 per hour.
• Developer 2 will work 50% of his time on the project at a rate of £80 per hour.
• Developer 3 will also work 100% on the project at a rate of £110 per hour.
• The Team Leader will work 100% on the project at a rate of £150 per hour.
• The Tester will be 100% on the project at £80 per hour.

The team cost per sprint (cps) will thus be…

Resource cost per sprint (cps) = <hours of resource per sprint> * <resource rate per hour>

• Developer 1 cps = 80h * £100 = £8,000
• Developer 2 cps = 40h (50% of 80h) * £80 = £3,200
• Developer 3 cps = 80h * £110 = £8,800
• Team Leader cps = 80h * £150 = £12,000
• Tester cps = 80h * £80 = £6,400

Total team cost per sprint = (sum of the above) = £38,400 per sprint

Project predicted Price = <Number of sprints (from Predicted Timeline calculation)> * <Team cost per sprint>

Project predicted Price = 10 sprint * £38,400 per sprint = £384,000

So the Fix Price Contract Values are:

• Price: £576,000
• Time: 20 weeks (10 x 2 week sprints)
• Scope: 300 Story Points

These simplistic calculations are of course just a part of the cost that will eventually get into the contract, but they are also the part that usually is the hardest to define. The way in which these cost are calculated also shows how delivering agile projects can be transferred into the contract negotiations environment.

Negotiating on Price

“So why is it so expensive?”, most customers ask.

This is where negotiations actually start.

The only factor a software company is able to change is its man-hour cost rate. It is the rate card that we are negotiating. Not the length of our iteration, not even the number of iterations. Developers, beyond popular believe, has no superhero powers and will not start working twice as fast just because it is negotiated this way. If we say we can be cheaper it is because we will earn less not because we will work faster.

The other factor that can influence the price is controlled by the customer – the scope.

Tracking Progress and Budget

Now that we have our contract signed, it is time to actually build the software within the agreed constraints of time and budget.

Delivering your fixed price project in an agile way is not a magic wand that will make all your problems disappear but it if measured correctly it will give you early visisbility. That is where the project metrics and more specific the burndown graphs come in to play. Early visibility provides you with the luxury of early corrective action ensuuring small problems do not turn into large expesive one’s.

One such a small mistake might be the team velocity used when the project price was calculated. Burndown charts are a very common way of tracking progress in many agile projects. It shows the predicted/forecasted completion of work rate (velocity) against the actual velocity to determine if the project is on track.

Figure 1 – Planned scope burndown vs. real progress.

They are good to visualize planned progress versus the reality. For example the burndown chart from Figure 1 looks quite good:

We are a little above the planned trend but it does not mean that we made a huge mistake when determining our velocity during the contract negotiations. Probably many teams would like their own chart to look like this. But the problem is that this chart shows only two out of three contract factors – scope ( presented as a percentage of story points) and time (sprints). So what about money?

Figure 2 – Scope burndown vs budget burndown.

The chart on Figure 2 shows two burndowns – scope and budget. Those two trends are expressed here as percentages for the purpose. There is no other way to compare those two quantities calculated (one in story points and the other in man-hours or money spent).

To track the scope and budget this way we need to:

• Track the story points completed (done) in each iteration.
• Track the real time spent (in man-hours) in each iteration.
• Recalculate the total points in your project into 100% of our scope and draw a burndown based on percentage of the total scope.
• Recalculate the budget fixed in the contract (or its part) into a total available man-hours – this is our 100% of a budget – and draw a budget burndown based on percentage of the total budget usedto date.

The second chart does not look promising. We are spending more money to stay on track than we expected. This is probably because of using some extra resources to actually achieve the expected team’s velocity. So having all three factors on one chart makes problems visible and iteration (sprint) 4 in this example is where we start to talk with the client and agree on mitigating actions, before it is too late.

Embracing Change

Agile embraces change, and what we want to do is to streamline change management within the fixed price contract. This has always been the hard part and it still is, but with a little help through changing the focus from the requirements analysis into some boundary limits early in the process, we want to welcome change at any stage of the project.

Remember earlier in the process changed fixed scope into fixed budget. The 300 story points from the example allows us to exchange the contents of the initial user story list without changing the number of story points. This is one of the most important aspects that we want to achieve with a fixed price contract done the agile way.

The difficulty here is to convince the client that stories can be exchanged because they should be comparable in the terms of effort required to complete them. So if at any point client has a new great idea that we can express as some new set of stories (worth for example 20 points) then it is again up to the client if we are going to remove stories worth 20 points from the end of our initial backlog to make a place for the new ones.

Or maybe the client wants to add another iteration (remember the velocity of 30 points per iteration?). It is quite easy to calculate the price of introducing those new stories, as we have already calculated the cost of a sprint.

What still is the most difficult in this kind of contracts is when we find out during the project that some stories will take longer than expected because they were estimated as epics and now we know more about them than we did at the beginning. But still this might not always be the case, because at the same time some stories will actually take less. So again tracking during the contract execution will provide valuable information. Talking about the problems earlier helps negotiating as we can talk about actions that need to be taken to prevent them instead of talking about the rescue plans after the huge and irreversible disaster.

Earning Mutual Trust

All the techniques discussed, require one thing to be actually used succesfully with a fixed price contract and that is – trust. But as we know, trust is not earned by describing but by actually doing. Use the Agile principles to demonstrate the doing, to show the progress and point out the problems early.

With every iteration we want to build value for the client. But what is more important, we focus on delivering the most valuable features first. So, the best way to build the trust of a client might be to divide the contract.

Start small, with some pilot development of 2 or 3 iterations (which will also be fixed price, but shorter). The software delivered must bring an expected value to the client. In fact it must contain some working parts of the key functionalities. The working software proves that you can build the rest. It also gives you the opportunity to verify the first assumptions about the velocity and eventually renegotiate the next part.

The time spent on the pilot development, should also be relatively small when compared to the scope left to be done. This way if our clients are not satisfied with the results, they can go away before it is too late and they no longer need to continue the contract and eventually fail the project.

Summary

Fixed price contracts are often considered very harmful and many agile adopters say that we should simply avoid them. But most of the time and as long as customers request them, they cannot be avoided, so we need to find ways to make them work for the goal, which is building quality software that can demonstrably increase business value propositions and competitive advantage.

I believe that some aspects of a fixed price agile contract are even good and healthy for agile teams, as it touches on the familiar while instilling commercial awareness. Development teams are used to working with delivery targets and business deadlines. That is exactly what the fixed date and price in the contract are – healthy time boxes and boundaries keeping us commercially aware and relevant.

Keep the focus on scope and you can still deliver your agile project within a fixed time and budget.

The intention of this article was not to suggest that agile is some ultimate remedy for solving the problem of fixed price contracts but to show that there are ways to work in this context the agile way.