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 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.
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.