Submitted by: Jan Van den Nieuwenhof on 22 July 2010
Comments: 0
This post is the second post in a series of three about Scrum in off-shore projects.
In the previous post, we explained some of our experiences in setting up a Scrum project with an off-shore team. In this post, we explain the contractual implications.
The next hurdle to take is to define the type of contract with off-shores. This is always a difficult exercise. You need a right balance of risk distribution between customer and supplier. Often you will have to go with fixed price agreements. There are two main options (both with pro’s and con’s):
You can take this approach if you have a pretty stable & clear product backlog. You ask your vendor to make a cost estimate per user story and you pay them accordingly.
o “Pro” is that you know exactly how much each feature will cost you, and you can assess the business value of each feature with more detail. If new features are added, or a feature changes scope drastically you just enter or adapt the estimate of that particular story, not on the whole contract.
o Of course if new features pop-up all the time, contract maintenance can start to be a very time-consuming task.
o Draw up your contract based on the part of the backlog that is clear and known. You ask a full estimate / fixed price for delivery of the backlog as it is know when you start the project. Ideally do this both in story points and man-days.
o The second thing you need to agree on is how to handle changes. We integrate in the contract how much scope is delivered for what price. When something changes along the road, new features need to be traded off with existing low priority features. This requires at least some trust from both sides, but in our experience we find this tends to work. Of course there is always a tendency to inflate estimates for new features on the supplier’s side. So it’s one the Project Manager’s tasks to be aware of this.
So actually you move
‒ away from fixed price, fixed time, fixed scope
‒ towards fixed price, fixed time, variable scope

Below you’ll find 2 other contract set-ups which are regularly used in Scrum projects:
This is the famous model of Jeff Sutherland. This model stipulates
a (negotiated) budget target to realize a certain amount of functionality (= business value).
The project stops when the business value is realized. The remaining budget (if existing) is split between customer and supplier. Often the split is done based upon profit margin of the supplier; so if the profit margin is 25%, the supplier will get 25% of remaining budget and the customer retains 75%. If the business value is not realized on the cost target, then you should actually fall-back on a time & material contract at cost price of the supplier.
is a variation on the fixed price per feature but extended to a larger time or scope box. The main driving factor is that you should fix the scope for one sprint / one release / one month. This is actually a full fix price but for a very limited amount of time & scope,which keeps it manageable.
Thanks for the post. I saw my day-by-day in a lot of sentences. We always need to get better on this way.
For sure TenForce has a lot of benefits. The greatest one is that it helps to save time!
All rights are reserved. No duplication without written permission. Copyright © 2002-2010 by TenForce.
TenForce - Haachtsesteenweg 378, 1910 Kampenhout. Belgium.
Post new comment