Personal opinion on software development in general, development methodologies, tools and best practices in particular

When you want to introduce Scrum in a fixed price project, the majority of people you’re talking to about this idea will immediately say that it’s impossible to use Scrum in a fixed price project.  Do they know that for sure? Did they ever try it? The answer to both questions is ‘NO’, no doubt about that. So why does everyone accepts that this combination is impossible?

Well, the answer is quite simple in fact. When people think about fixed price, they implicitly think about fixed budget, fixed time and fixed scope. And yes it’s true that a fixed scope and Scrum can’t go together. That’s quite obvious because one of the base principles of Scrum is that scope just can’t be fixed. That’s the idea behind the product backlog: at the beginning of a sprint, the team commits themselves to implement the most valuable stories at that moment before the end of the sprint. But the sequence of stories and even the content of the product backlog -except the stories the team is committed to-itself can change at any time.

But fixed time and fixed budget are absolutely no problem with Scrum. An argument I hear a lot is that you can’t set a deadline at the beginning of the project because you don’t know what will be delivered in the end. Because you don’t know what will be delivered in the end, you don’t know when it will be finished and you don’t know what will be the total cost of the product.
Well in my opninion, in a traditional waterfall project when people negotiate about what will be delivered, when and how much it will cost in the end, they also don’t know how long it will take and what it will cost. That’s why most sales people and project managers multiply the initial estimations with a factor 3. And even then, when the deadline is reached, still a lot of issues need to be fixed and the customer will have to pay a lot for that.

Another fact is that the customer can’t predict the future. It’s stupid to think that a person can know all features he wants in a year. Of course his mind will change! Of course he will change his mind when he tests the product! And that’s what most consultancy companies know. So they can make a lot of money by implementing change requests. So the fact that you can’t predict the price of a product on beforehand is just true. But there’s no difference between waterfall and Scrum projects…

The problem is that people want to use the same practices in the offering phase with Scrum as they are used to use with waterfall and that’s a wrong mindset. You can already create a general coarse grained product backlog at that time. Based on that backlog, a minimum set of functionalities can be defined and budget and deadline can be defined.
One can make use of the principles ‘money for nothing’ and ‘change for free’.

Change for free means that the customer can replace stories from the backlog with other stories with the same amount of storypoints at any time without any extra cost. This guarantees that in the end, a customer will get the product he wants and won’t pay more for it than initially estimated.

Money for nothing means that the customer can say that he has enough functionality delivered at any time he wants, even when not all functionalities from the initial set are delivered. The customer will have to pay a fee to the consultancy company but in the end the price per functionlity will be cheaper than what they agreed upon.

So to conclude: a better name for fixed price would be fixed budget. And fixed budget and even fixed time can go hand in hand with Scrum. The best Scrum contract model is called ‘Variable scope and cost ceiling’.

Comments on: "Scrum and fixed price: impossible?" (5)

  1. […] impossible to use Scrum in a fixed price project. Do they know that for sure? Did they ever try… [full post] glenndejaeger about:software development methodologyscrumsoftware development 0 […]

  2. […] This post was mentioned on Twitter by Shawn Clark, glenndejaeger. glenndejaeger said: Scrum and fixed price: impossible?: […]

  3. Jordan said:


    Although this makes sense you are changing the notion of fixed cost.

    When most people want “fixed cost” they also want “fixed scope”.

    You are addressing that in Scrum by making the scope variable.

    That is not the same as a fixed/minimum scope along with fixed cost, which is what most people are wanting to buy in such a scenario.

    Also your last graph I’m having trouble understanding; it seems to show the same curve as the previous one, with the exception that the last one is rode out to the “do everything” scenario, and thus maximizes profit.

    How do you maximize profit without doing the “do everything” scenario, especially if you allow the customer to abort when they have the highest ROI but not yet highest profit?

    • Hi Jordan,

      What I meant to say was that when people think about ‘fixed cost’, they actually mean ‘fixed cost for a fixed set of functionality’.

      Because 1 of the base concepts in Scrum is that the scope isn’t fixed, you ‘ll have to convince people of the fact that they pay for an amount of fucntionality, but the content of that functionality that’s deliverd can be different from the functionality that was initially agreed upon.

      The last graph is indeed almost the same as the previous one. The last one shows a contract model that fits best in Scrum projects while the previous one shows a principle which can be used in every type of contract you want.

      In fact the last graph shows only a part of the previous one. It just tells that for maximum profit for the consultancy company and for maximum business value for the customer (=win-win), you’ll have to stop developing at a certain point. If you do everything it means that the customer will pay for additional functionality which doesn’t add much business value. And for the consultancy company the ROI won’t grow anymore. So for both parties it’s the best not to deliver ‘all’ fucntionality but only that part that has a high business value.


  4. Han van Roosmalen said:

    Hi Glenn,

    I certainly see some of your points as you mentioned. However there are some trade-offs you have to make when you are the producer of the software.
    When can you deliver value with the software you produce?
    Many times it takes more than a few weeks when the customer is able to see any potential profit coming in. So at the moment of the fixed-price contract both parties will have difficulties saying something concrete about this.
    Only when the customer has a very clear vision of the market potential of the software product and a very clear vision of what should be included then requirements can be set pretty fixed.

    So what is the right moment to sent the last invoice?

    And what is the right moment to stop producing?

    In practice it takes time for the customer to test and accept the software. And what should the producer do in the mean time? Start another agile project?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: