Agile Team Meets a Fixed Price Contract

Posted by Marcin Niebudek on Jun 30, 2010

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Value ,

Agile Techniques ,

Agile ,

Delivering Quality ,

Change

Tags

Planning ,

User Stories ,

Contracts & Negotiation ,

Budgets

Fixed price contracts are evil - this is what can often be heard from agilists. On the other hand those contracts are reality which many agile teams have to face. But what if we try to tame 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.

So let's start with the contract itself.

Fixed Price, Time and Scope

Fixed price contracts freeze all three magical factors at once – money, time and scope. Are the price and time a problem for agile teams? Well they shouldn't be. 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 it. The only thing they don't know is what exactly they want to get (even if they insist they do know).

The problem of fixing the scope has its roots in:

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

Every fixed price contract has a companion document, the “Requirements Specification” or something similar. This document 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.

Key wrong assumptions in fixing the scope are:

• The more detail we include in the 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

Moving from Fixed Scope to Fixed Budget

Now, when we understand that the main conflict between application of agile mindset and a fixed price contract lies in the fixed scope, we can focus on converting the fixed scope into the fixed budget.

This means that instead of providing detailed specification of requirements we need to focus on catching as many of them as possible in the form of user stories. We need to build an initial product backlog which we will try to estimate using the story points technique along with whole-team estimation techniques like planning poker.

First, we need to understand that a higher level of detail in software requirements specification means two completely different things for both sides of a contract. Software companies will usually focus on technical details while the other side is more business oriented. Specifications are usually created by a software company and are usually very protective. This is the place where the three key players come to play.

User stories as a way of expressing requirements are understandable for both clients and vendors. 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.

Story points as a way of estimating stories are harder to explain to the client in the beginning because they are not a common way of expressing the effort. But in return they lower the risk of underestimating the scope. How does this happen? Story points in their nature are relative and focus either on the whole scope or on the groups of stories, while traditional estimation (usually done in man-hours) tries to analyze each end every 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 be not so obvious what it means to implement a story. Teams who discuss their definition of done with the client know better what are the client's expectations. They also estimate better. In addition, on the client side, the definition of done creates high level criteria for user story acceptance.

For example the definition of done for stories in the newly created web application may introduce such criteria as:

• Tested under IE 7/8, Firefox 3.x and Chrome
• Corresponding section in the “Users Guide” created

Later on the team can put some other, more internal elements of the definition of done, but at the stage of building a contract those general guidelines give an understanding between the Client and the team about what we all want to build within a defined scope.

Hopefully, having our definition of done in mind we will come up with some value defining our scope budget in points. And this value, not the stories that are behind it, is the first thing that should be fixed in the contract. This opens the door for change.

While we have the scope fixed (in terms of points) we still want to embrace the change the agile way. We have the tools (user stories and points) which we can use to compare one requirement with another. This allows us to exchange requirements along the way within a defined scope limit. And if we can stay within that limit, we can also stay within the fixed price and time.

Initial Estimation

The hardest part in preparing a fixed price contract is to define the price and schedule that will be fixed based on the well-defined scope. Let's look how can the team contribute to such a contract with initial project estimation done the agile way.

First, 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. Often we need to do that even earlier when preparing an offer for the client's Request For Proposal (RFP).

The next step is to gather user stories. This can be arranged as a time-boxed session 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 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 demo session)
• How often do we meet and who participates
• etc.

This and probably many more factors specific to your project 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.

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.

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.

Fixing 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. So how to get them? We need some magic numbers.

We should not be surprised by this as in fixed price contracts there have always been the magic numbers. All estimated values have always been such numbers. Right now we are changing the way we estimate but at the end we also need to predict the future based on the knowledge we have of the past. So what do we need to know? It's the predicted team's velocity.

Lets assume we estimated our stories for a total of 300 points. We need to determine the velocity that our team may have based on:

• The team's velocity on earlier projects
• The number of activities we need to do in our iteration (see the definition of done)
• The ease of communication with a client (of course the ideal and hard to achieve goal is to have a client on site as a part of the team, but usually this is not what we have and clients have different amounts of their time that they are willing to spend with our team) – the less time our clients have for us, the lower our velocity
• Just a feeling we have when looking at the scope (yes, good ol’ wishful thinking)

Let's say we have a team of 5 people -- 3 programmers, 1 tester and 1 team leader -- who will communicate with clients and stakeholders as well as any other people outside of the team (like a Scrum Master in a Scrum methodology).

We may now decide that our team will try to achieve a velocity of 20 story points per 2 week iteration. This is our main magic number in the contract. 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)

Scenario 1

In the first scenario we can determine the predicted time to finish using the formula:

time = (<points> / <velocity>) * <iteration length>

So in our example it would be:

time = (300 pts / 20 pts) * 2 weeks = 30 weeks (or 15 iterations) 

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 extend the team, however this is not working in a linear way. So doubling the team size will never double its velocity.

Scenario 2

We know that the deadline comes in the next 20 weeks, which are only 10 of our iterations, so we can do only 200 points from the scope. Now it is up to the client to decide what can be removed from the scope without losing the ability to deliver something with the required business value.

Here also (to some extent) we can change the size of the required team to be able to expect higher velocity.

Knowing required team size and target finish time we can finally calculate the main part of the price for the contract – the working time cost:

money = <hrs per iterations> * <no. of iterations> * <people> * <hour price>

In our example we would have:

money = 80 hours * 15 iterations * 4 people * $100= $480,000

So now we have fixed price contract values:

• price - $480,000
• time - 15 iterations (30 weeks)
• scope - 300 story points

Those 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. What we were trying to show here is that the way we work in agile projects can be transferred also to the contract negotiations environment.

There is one more question to deal with. The client asks “why is it so expensive?” This is where negotiations actually start and one thing we want to mention here is that the only factor a software company is able to change is its man-hour cost rate. It is those $100 that we are negotiating. Not the length of our iteration, not even the number of iterations. Our team has no superhero powers and will not start working twice as fast just because we negotiate it this way.

It is the money that we are willing to lose. If we say we can be cheaper it is because we will earn less not because we will work faster.

Tracking Progress and Budget

Now that we have our contract signed (that was easy right?), it is time to actually build the software within the agreed limits. You might have already heard that agile will not solve your problems but it will make them visible. That is why we want to know early how we are doing so that we take proper actions. There is a chance that the magic number (our velocity) from the fixed price contract was a mistake.

Burndown charts are a very common way of tracking progress in many agile projects.

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 and time. 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 in percent 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).

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 4 in this example is where we start to talk with the client before it is too late.

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 used so far

In our previous examples we had:

• The scope of 300 story points
• The budget of 30 weeks * 4 people * 40 hours a week = 4,800 man-hours

Those would be our totals. So spending 120 hours to burn 6 story points would mean that we have burned 2% of our scope using 2.5% of our budget.

Embracing Change

We need to get back one more time to the point where we changed fixed scope into fixed budget. The 300 story points from the previous examples allows us to exchange the contents of the initial user story list. This is one of the most important aspects that we want to achieve with a fixed price contract done the agile way.

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.

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 20 points per iteration?). It is quite easy to calculate the price of introducing those new stories, as:

money = 1 iteration * 80 man-hours * 4 people * $100 = $24,000 

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 Trust

All those techniques require one thing so that they can actually be used with the fixed price contract - trust. But as we know, we cannot earn it just by describing what a great job our team is going to do for our clients.

Agile principles bring one good idea for solving this problem. 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 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 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 to 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 they cannot be avoided, so we need to find ways to make them work for the goal we have, which is building valuable quality software.

Actually, some aspects of fixed factors are even better for agile teams since we are used to working within time boxes and that is exactly what the fixed date in the contract (and also fixed price) are -- just time boxes and boundaries. The only thing that actually bothers us is the scope and with this article we tried to gather together ideas on how to deal with that limit.

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.

About the author

Marcin Niebudek is an entrepreneur and co-owner at Agilers, and creator of tinyPM, a lightweight agile project management tool. Marcin is insanely idealistic about software development and strongly believes in it as a craft. He enjoys experimenting with all flavors of Agile and Lean Development techniques. He also loves to write software, read about software, think about it, and blog about it. Author of an agile blog, “Battle for Agility”, which describes agile movement in Polish IT, he is a mostly-Java developer with 8 years of experience in building enterprise systems leveraging all kinds of technologies from a Java EE stack.

1. Back to top

   magic numbers

   by Jay Dub

   Nice article.
   
   My experience is that clients not used to working in this manner are very contract-specific - to the point of even putting the features and estimates inside the contract.
   
   Have you used techniques where is movement in the contract for fluctuations in the velocity?
   
   I heard of one organization who wrote a clause that if the team came in over estimate on an iteration, the client would only have to pay 50% of the extra cost, and if they came in under then the client would get 50% of the savings back. I am not sure how this worked in practice but is an interesting approach.

   Reply

2. Back to top

   Re: magic numbers

   by Marcin Niebudek

   No I haven't tried this approach, but I prefer the other one. If client does not accept the deliverables of an iteration he does not pay for them. This is a perfect motivator to keep the communication with the client close and pay attention to what he really wants.
   
   Of course we can add some restrictions on high velocity changes, but I thing the most important is to keep the contract as simple as possible without to many strict rules which can be gamed later by the team (If I pay a penalty for the velocity loss I'll make it stable anyway, not necessarily due to better planning).

   Reply

3. Back to top

   About difficulty of estimating user stories

   by Tarik Fdil

   Very interesting article. It helped me understand some of Agile concepts. But, since I'm new in Agile-like methodologies, there some others ideas that are still obscure :
   
   1 - I think it is very difficult to find the building blocks to the baseline estimates (user story with 1 or 2 points) and then make the relative comparisons. This can be very risky and prone to errors. So we haven't solved the main problem of fixed price contract : wrong estimate of time/price.
   
   2 - Using Fibonnacci numbers seems a little magic for me. We may as well use an increasing sequence of (prime) numbers. The underlying problem doesn't change.
   
   3 - Choosing story points instead of hours x men or functional points does not change the problem of estimation. Moving from one measure to another is a simple matter of conversion.
   
   Voila!
   
   Tarik

   Reply

4. Back to top

   Re: About difficulty of estimating user stories

   by Marcin Niebudek

   Thanks Tarik,
   
   Rusell Pannone posted a very good recipe (at least I like it very much) for estimating seto of stories when you have a low confidence in your velocity. You will find it at Ask About Projects.
   
   As for Fibbonaci numbers or story points in general the actual values do not matter, but their relative nature does. So prime number would be as good for me.
   
   What is important for me in the story points/planning poker tandem is the relativity of points and collaborative way of estimation using poker which represents the teams point of view on the problem complexity, while function points will rather focus on the raw complexity of the problem treating the team as an "average team of N developers".
   
   But of course the method you will choose is up to you. The point is to agree on some total budget (if it's in function points, let it be) and be able keep estimating easily any changes the same way after the project launch, so you can change requirements withing that agreed budget.
   
   Regards,
   Marcin

   Reply

5. Back to top

   Re: About difficulty of estimating user stories

   by Tarik Fdil

   Thanks. Nice recipe indeed.
   Furthermore, I totally agree on your last paragraph!
   
   Regards
   Tarik

   Reply

6. Back to top

   Re: magic numbers

   by C Curl

   "I heard of one organization who wrote a clause that if the team came in over estimate on an iteration, the client would only have to pay 50% of the extra cost, and if they came in under then the client would get 50% of the savings back. I am not sure how this worked in practice but is an interesting approach."
   
   Where I work we commonly use this approach to agile projects. It works better for clients who really want to know how much the software they want is going to cost them. With a fixed-price contract you end up loading on risk factors to the price, and trying to nail down the details of scope at the contract stage. With target price, or incentive contracts you share the risks and rewards with the clients. You do go into overall scope of the solution in sufficient detail to allow you to estimate it. Both parties have incentives to meet the price, but neither party are unduly punished if it doesn't, and you can avoid much of the blame game should it miss the target. Also, the client has the opportunity to work out the details and change their mind later on (usually on a like-for-like basis - e.g. swapping one 3-point story for another), without incurring hefty fees for raising change requests.
   
   If it's a government procurement project, there are some sure obstacles to derive the "magic number" (a.k.a velocity) using the approaches described in the article. It's unlikely you'll have many meetings with client until the final negotiation stages, the team you're putting to the task will probably not have worked together before (unless you're a very small one client company), and you won't know it's velocity from earlier. Also, although it's a great practice, it may be difficult to get time for the (planned) team to get together to do the estimates if they are working on other projects or for different clients.
   Maintenance projects are much simpler in this regard - it's easier to use the existing team's experience with the system to plan the effort and project the velocity.

   Reply

7. Back to top

   Fixed price contracts is fixing time, scope, money?

   by Yves Hanoulle

   i'm not sure I agree that a fixed price contract means fixing the three variables.
   For me the best explaination of how fixed priced contract could be don in agiel was writing by Pascal Van cauwenberghe
   www.nayima.be/html/fixedpriceprojects.pdf
   www.nayima.be/html/agilefixedprice.pdf

   Reply

8. Back to top

   Re: Fixed price contracts is fixing time, scope, money?

   by Marcin Niebudek

   Thanks Yves for pointing those articles. I just scanned them quickly and will surly get back to them for one more detailed reading...
   
   As for fixing all three variables... well it's not something that I can also agree with, but in the other hand (at least in my experience) it's the most common approach to that kind of contracts. So here I also wanted to focus on loosening the "scope" variable and have only two of them fixed.

   Reply

9. Back to top

   Re: Fixed price contracts is fixing time, scope, money?

   by Yves Hanoulle

   @Marcin
   yes loosening the scope is also what Pascal wrote.
   If it is the most common approach, I think that is because people don't know any better.
   I still have to meet the first customer that does not agree with what Pascal wrote.
   Usually the customers are well aware that fixing all three variables is a disaster waiting to happen.

   Reply

10. Back to top

    Re: About difficulty of estimating user stories

    by David Peterson

    Since when were 20, 40 and 100 Fibonacci numbers ;)

    Reply

11. Back to top

    Outcomes over features

    by Kevlin Henney

    Dan North's blog from a few years back has some interesting things to say about the distractions of scope and scope management:
    
    blog.dannorth.net/2006/10/28/outcomes-over-feat...

    Reply

12. Back to top

    Contracts comparison

    by Dandik M

    Worth to check this when thinking about the contracts:
    
    agilesoftwaredevelopment.com/blog/peterstev/10-...

    Reply

13. Back to top

    Re: Contracts comparison

    by Chris C

    In regards to quoting contract values
    * price - $480,000
    * time - 15 iterations (30 weeks)
    * scope - 300 story points
    be very careful of including the 300 story points as part of the contract because
    1) Story Points can be gamed by estimating work to be larger and therefore the team can appear to have increased their velocity;
    2) Stories are often re-estimated as we learn more and hence may change and
    3) the client (or even worse, management) may start anchoring story points to a dollar figure which is not what you want - according to the values above, 1 story point costs $1,600.
    
    These can have unwanted side effects to the project.

    Reply

• Older >