Fixed price contracts are often considered very harmful and many agile adopters say that we should simply avoid them. But most of the time they cannot be avoided, so we need to find ways to make them work for the goal we have, which is building valuable quality software. The only thing that actually bothers everyone in fixed price agile contracts is the scope. Scope in agile is equivalent to delivered ‘business value’ as opposed to WBS in traditional projects. The requirements are depicted as epics, features or stories depending on the level of granularity.
Measuring Scope in Agile
Scope in agile is measured as ‘Size Units’. There are many conventions to measure size; story point measurement is a popular method. Examples of size units are:
- Story points
- Feature points
- Epic points etc.
For agile project management to be implemented in fixed price projects, three scenarios exist:
1) Requirements are available and stable, so it is the most easiest agile fixed price project
Highlights:
Single contract with a single statement of work (SOW) Contract Type: fixed price
2) Requirements are available partially, and there is a probability of requirements changing
Highlights:
One contract; Two SOWs Contract Type: Fixed price + fixed price
3) Requirements are not at all available, so we have to look at innovative approach to structure the fixed price contracts
Highlights:
One contract; Two SOWs Contract Type: Time & Material with cap + fixed price
