An Approach for Scrum in a Fixed-Price Contracts World

March 15, 2013

6

We know a fixed-price contract is maybe not the best alternative when applying Scrum to a software development project. However, some organizations will not change the way they approach contracts for software development projects. What if this organization is Waterfall-minded and is going to experiment with its first Scrum project? What if the RFP has a set of fixed requirements?

In our case, the latter is the most frequent situation we run into, and we needed to find a way to somehow make Scrum feasible. I would like to share our experience.

The RFP

The first step is the RFP. Sometimes the RFP has a unique list of clear requirements (which we know will change), and sometimes the RFP has an ambiguous narrative description of the product. Whatever the case, an organization will hardly have a clear product definition at the beginning. Our mission is to deliver the highest value we can, so maybe we would be tempted to create some user stories and some epics. However, we should also consider that if we have too many epics in our proposal, we may fail big and end up losing money. Nobody wants that.

So what we do is transform the RFP scope in a product backlog. We try to avoid epics and create a backlog full of user stories whose cost is feasible for our proposed fixed price. We know that trying to be specific implies waste, but we consider that part of the cost of sales. Regarding value, we will have an opportunity to fix that at the beginning of project execution, as we see in the next section.

Deliverables

What about deliverables? Traditional fixed-price contracts are based on traditional Waterfall deliverables, such as analysis document, design document, etc. This is where we have to make use of negotiation and persuasion skills for explaining that they will have the required documents, but at some other moment during the project. Some documents will be created incrementally if our Definition of Done says so, and some will be created at some specific point — usually after development or user acceptance phases. Our development phase deliverables will be working software demos ready at the end of each iteration. Worried faces are usual at the beginning.

Reviewing the product backlog

As part of the methodology, we propose a revision of the product backlog as the very first step in the project. Conversations during this ceremony are quite interesting. One example is when the scope was defined months ago and customers are worried because of an out-of-date scope. These are the ones who will like Scrum the most.

The first thing we do in this meeting is present the product backlog. Each user story will have a number that represents its size. We like using kilos for size. At this point we explain to the customer that he has bought "the right to n kilos of work." Then we explain the Scrum process and wait for the two classic questions:

  • "What if we use more Kilos?" We answer nicely but simply: You pay.
  • "What if we use fewer kilos?" There are a number of alternatives for answering this question! It has never happened for us that a project ends with fewer kilos than planned, though.

We also communicate that the product owner is the king of the product backlog. The desired output of that scenario is a defined product owner and a language of product backlog items and kilos. Sometimes, for reducing the size of change, the term "user story" remains internal to the team and we use "requirements" with the product owner and other stakeholders.

Management of product backlog and change control

One of the concerns of the product owner is the total number of kilos. We review it during iteration planning and iteration review meetings. Usually, if the customer organization has a significantly bigger product backlog full of high-value items, there will begin a change-control process for increasing the number of kilos they have available.

Share on Facebook    

Article Comments

  1. Anthony (Tony) W. Shawver said on 15 Mar 13 08:08:
    I like to see more articles these Professional Services focused topics with more depth.
  2. Scott Ocamb said on 16 Mar 13 11:45:
    Manuel, do you have any thoughts on how an estimate, price and timelines are derived?
  3. Manuel Borja said on 16 Mar 13 16:15:
    That is a good question. It's very different from company to company so I will describe my personal approach. Let's suppose the team will work full time in one only project so it does not get complicated. Let's suppose it's a software development services company. Estimating First of all, you need to know the velocity of the team (a task can demand 4 hours of development effort but it can last 6 calendar hours because of other factors like meetings and googling). Then you estimate the whole product backlog in calendar hours (some group planning technique recommended). Then you have the total calendar hours needed for the project. Duration Simple division: Total Calendar Hours / (Calendar hours available per week) For example. If the project needs 800 calendar hours and my team has 80 calendar hours available per week then I need 10 weeks) At this point you should decide the size of the sprint too. Then you have duration and sprint size. You could think of dependencies and staff like that but well, how important that is depends on every project. Usually it does not matter that much. Price First of all, you need to know the hourly cost of each team member, which maybe should be a company standard. Then, the cost of the project is calendar hours x price plus travel expenses, specific insurance if needed, etc.). Then, unless you are a non-for-profit organization you want to include risk and profit at this point. Even if you are very good at estimating there is always a probability for unknown unknowns to occur so you should consider some risk. And I guess the more trust you create the more you can add to your margin :) There are so many factors in this process but that is my personal way of proceeding. Finally, requirements like "powerful search screen" or "analytical report" cannot be allowed, no such an epics when you have a fixed price contract or you will end up doing Harlem Shake for money.
  4. Kazi Sharifuddin said on 20 Mar 13 13:27:
    In a traditional fixed price contract, there is upfront requirements, estimations, designs, initial sign-off and adherence to contract based on Milestones/deliverables & later handle addtl requiements thru Change request. For e.g. Technology upgrade projects, migrations or even small development where requirements are pretty clearly defined and very low probability of change. However, if the same is converted to Scrum based there is much more involvment from users and commitment of time. What are the benefits in this case and the justification/incentives for the client doing scrum?
  5. Kazi Sharifuddin said on 20 Mar 13 13:28:
    In a traditional fixed price contract, there is upfront requirements, estimations, designs, initial sign-off and adherence to contract based on Milestones/deliverables & later handle addtl requiements thru Change request. For e.g. Technology upgrade projects, migrations or even small development where requirements are pretty clearly defined and very low probability of change. However, if the same is converted to Scrum based there is much more involvment from users and commitment of time. What are the benefits in this case and the justification/incentives for the client doing scrum?
  6. Manuel Borja said on 20 Mar 13 19:55:
    Kazi, Nice comment. I know there can be projects where requirements are very well known in advance. I haven't had the luck to be part of one of those though. In my experience, most of the software development projects with upfront requirements are very good potential candidates for an agile approach. In these cases, we want the customer to get the most value of the product. Even if the customer thinks a traditional fixed price is the best approach, they will end liking the agile approach for sure! The first meeting where you explain you will be working by sprints is a key one. The first iteration review meeting is a great experience. They expect documents and you show working software.

Please login to comment on this article.

Author

073aa39

Manuel Borja CSM, CSD, CSP

bio

Manuel Borja started as a software developer in the late 90s and since then he’s played the roles of business analyst, software developer, software architect, technical leader and project man... Link »

Tags