Get certified - Transform your world of work today

Close

Writing a Scrum Contract

30 December 2015

Amit Kulkarni
Effective Project Management Consultancy


The most common type of contract used in Scrum is either time and materials (T&M) or a pseudo-fixed price. Pseudo-fixed price is just a T&M contract with the cost of each sprint defined as resource hours multiplied by the rate. The true fixed-price contracts are the ones for which the utmost care has to be taken; otherwise, the team will find itself working on a worse-than-Waterfall project.

I have lead many projects in Scrum and dynamic systems development management in Europe and have observed some common mistakes managers make in writing a fixed-price Scrum contract. For example, Scrum contracts are written in the same way as traditional contracts, and the managers add only the "will be done in Scrum methods" line in the contract. In the traditional contract, the cost and time are always variables, with some change of budget or contingency added. However, the customer argues that because it's Scrum, and that the concept of timebox applies, the contingency and the change budget inherently get removed. This makes the contract fixed time, fixed cost, and, of course, fixed scope.

I suggest the following modifications to traditional fixed-price contracts to make them applicable to Scrum:
  1. Modify the scope section by using the MoSCoW principle (the Musts, the Shoulds, the Coulds, and the Woulds).
  2. Use the Shoulds and Coulds as a scope tolerance when the customer asks for changes to be incorporated. Obviously, you will adapt to the customer changes, but then the customer should also understand that the scope cannot be fixed and that there is always a cost for the change. It is just that the cost of the change is taken in terms of knocking off some of the scope from the Shoulds or the Coulds.
  3. Include a condition that states that the scope is flexible, but when it is added to the Must section, it is fixed. However, the scope written in the Should and Could section is "negotiated" based on the changes suggested by the customer.
Leave some room for the negotiation of scope in the contract. Otherwise, you will find your team doing a fixed-price, fixed-scope, and fixed-time contract, which would be really unfortunate for the team.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.6 (10 ratings)

Comments

Rene Wiersma, CSM, 12/31/2015 5:43:02 AM
Thanks, Amit, for writing this article. In my experience clients find it very difficult to divide the scope into Must, Should, Could and Woulds. In their eyes *everything* is important and crucial to the success of the product. Also, their fear is that, if something is defined as anything lest than a Must Have, the vendor will consider it as a free pass to not build it. In the requirements sessions in which I participated after a lot of nudging and urging the client may agree to define about 10% of the scope as anything less than Must Have. Did you have similar experiences when defining scope?
Srinath Chandrasekharan, CSP,CSM, 1/4/2016 3:19:29 AM
Amit, I work with HCL and many of the contracts are Fixed Bid ones here. Like you rightly said, these type of contracts really are bad for the team. What I have seen here ( which is in line with what Rene has mentioned) is that most clients know only a small percentage of their complete requirements. This is more so for an application / site development and I have seen something very similar in plat / technology migration situations as well. In the second case, most customers want to add new features as well which makes it somewhat like a new development. Asking them to define the priorities is almost impossible. What we have tried here are various things ( in case of Fixed price).

1. We try and explain that any changes to the requirements will swap out an equal sized but lower priority requirement. Thus the client keeps the budget in check and has the flexibility even late in the project life cycle to add / remove requirements

2. We try and have a T & M requirement phase where the Product Backlog is frozen ( maybe 80%) and then give a fixed bid quote ( with appropriate assumptions and margins for error)

3. We have clauses in the contract where we say that project estimates will be revisited at specified intervals and all estimations etc. will be transparent.

While these measures have helped, it really depends a lot on the client's understanding of Agile and willingness to collaborate. Otherwise its always a tough and bumpy ride , especially in Agile projects.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe