SCRUM with Fixed Price-V2.0

SCRUM with Fixed Price (FP) – Feasibility, Risk

Exposure and Structuring

2 | P a g e Author: Shyam Singhal

SCRUM with Fixed Price (FP) – Feasibility, Risk Exposure and Structuring

1 ABSTRACT

Days of long running T&M projects are fading fast, with the market moving towards Fixed

Price (FP) contracts. In order to sustain our business and increase our market share in

services, we must improve our capability to service FP contracts.

SCRUM is known for providing the flexibility of defining requirements at a high level, which

get progressively refined during each sprint. It also provides customers the flexibility to re-

prioritize the requirements, re-build the product backlog, and opportunities to incorporate

feedback at regular intervals by working through either intermediate builds or through

production ready incremental builds.

Since SCRUM provides so much flexibility to customers and it is difficult to firm-up the full

scope of work at the beginning, these kinds of projects are typically managed via a Time &

Materials (T&M) pricing model. Other types of pricing, especially Fixed Price, exposes the

vendors to much greater risk.

It is also true that these days customers want to know their costs upfront, and at the same

time want to have the flexibility to make course corrections during the execution of a

project, if required. These are conflicting needs which, are prevalent in today’s competitive

world. The vendors are often willing to take these risks in order to win the business away

from their competitors.

The question is, how to compete in this landscape and grow our market share but not

expose ourselves to excessive risk? What are the options available to us, to manage this risk,

such that even this business is viable?

We propose the following two main options to minimize risk:

1) Fixed Price, but Scope is variable – ‘Capacity Based’

a. Fixed Price, Scope, and Duration, but for a Sprint – Sprint based FP

b. Other combinations of Price and Delivery Execution Methodologies

2) Fixed Price, Scope and Duration – Variable for initial requirements gathering, then FP

– Customized Iterative Development

Each option requires discussion with the customer to assess the compatibility of

requirements with stated option. It also requires sales / delivery to have discussions with the

customer to make them understand the conditions under which each option works. A

walkthrough is mandated, as any amount of documentation may not yield the same results.

The intent of the discussions is to persuade the customer to identify the underlying business

needs and maturity of their requirements, instead of getting into a Pricing Model and



Delivery Execution Methodology discussion. This helps in opening up more options, instead

of having a situation of ‘take it or leave it’.

How do we respond to situations where we have no option but to respond to “Fixed Price,

Scope and Duration – True Fixed Price deals, at pre-sales stage itself” or leave the deal?

There is no easy way or shortcut to make this a viable business proposition – it requires a lot

of discussion with the customer and preparation in structuring the response to make it

viable.



2 INTRODUCTION

The literature on SCRUM suggests that agile practices can’t work with Fixed Price (FP) pricing

models. The basis for this understanding lies in the fact that we uncover the details of the

requirements in each sprint, and each sprint’s backlog keep changing because of

prioritization of requirements, either because of business priorities or because of the work

accomplished thus far.

It is also true that more and more work is preferred to be done (rather required to be done)

in agile way, as in today’s dynamic environment, it is extremely difficult to get all the

requirements upfront, and expect no changes in those from that point on. What it means,

whether we like it or not, prepared or not, it is riskier or not, want to change or not…we need

to prepare ourselves for this changed field, if we were to sustain our business, let alone the

competitive edge etc.

In a way it is not new. It should have happened much earlier. As we have seen in many other

industries, it is a consumers’ market, and sooner or later it was bound to infiltrate in IT too. It

is simple Economics, the demand and supply.

If it was bound to come, and now, even if it has been thrust upon us, what is the answer we

have for changing business environment? How can we provide a ‘Fixed Price’ quote for

something, when we don’t fully know the requirements? Usually, we do know some (but not

all) requirements. We need to better understand what the customer means by ‘Fixed Price’:

1) Price, scope, and duration are fixed – True FP, at pre-sales stage itself?

2) Fixed price, but scope is variable – ‘Capacity Based’

a. FP – Price, scope, duration are fixed – Only for a Sprint; Sprint based FP

b. Any other combination of ‘Capacity’ and ‘Delivery Execution Methodology’

3) Price, scope, duration are fixed – Variable for initial requirements gathering and

design, then FP – Customized Iterative Development

May be, we have to work a little to understand the real requirement (pricing model) of our

potential client; however, it still provides some hope, for it being a workable solution. The

point is, we need to understand customer concerns and constraints, and why he is insisting

on FP, capacity or budget etc. Once we understand the constraint, we are better equipped to

respond to customer requirement.



3 PROBLEM STATEMENT

A customer may not be knowing the scope of work upfront; however, has a fair amount of

idea in terms of needs, i.e. these needs may not have been formed as ‘requirements’. At the

same time, customer has a limited budget (who does not) for the need that he has to fulfill.

In addition, the customer wants to build the system in such a way that he has the ability to

change the requirement, re-prioritize the requirements, and have an operational / working

model / system at regular intervals.

It sounds like best of worlds for customers, and worst for vendors who agree to fulfill these

needs.

In nutshell, how do we provide a FP option for a scope of work which will get progressively

elaborated and built, where the customer has the flexibility to re-prioritize the work and

mandate an operational / working system at short and regular intervals?

4 PROPOSED SOLUTION

As it stands, an opportunity with fixed scope, fixed duration and fixed fee, where scope will

be determined progressively, is very hard to respond to. This is similar to asking a builder to

construct a building on a fixed price and schedule without knowing any details on the

materials, design, area, usage, etc. of the building, but allowing the flexibility to change the

design as the building is being built.

It is obvious that getting into any fixed (scope, duration and fee) agreement of this kind is

not only risky, but we have no means to asses and know our risks in the absence of any

detailed information. We have two options to manage this situation:

1) Have a discussion with customer, channeling it in a direction of presenting

various other approaches that allow the customer to manage this ambiguity

2) Have a discussion with customer, or determine through some other means, a

way to reduce the ambiguity in such a way that we are able to assess the risk

that we will undertake.

4.1 OPTION – 1: PRESENTING ALTERNATIVES TO FIXED SCOPE, DURATION AND FEE

4.1.1 Capacity Based Fixed Price

This is the least risky model for any delivery: we are committing to deliver a scope that

can fit into contracted capacity (effort), within constraints of contracted duration. If



necessary, the cost for that capacity can also be fixed, since we are committing to work,

as per contracted capacity. This provides the flexibility to customers as well as do not risk

the contractor / vendor either. However, it requires complete transparency in operations,

right from estimation through deployment and support.

One may think that since this is FP, why should he provide internal operational details of

the project / program to customer? We must not forget that the FP is for ‘Capacity’ and

not for scope. Therefore, it is imperative that we provide the same comfort to the

customer by providing this transparency in our operations. This helps build the required

trust as the customer is taking a risk of buying a capacity, though still not sure, whether

the work will get completed within that budget or not.

The important aspects of this model are;

We should document the capacity breakup in terms of ‘Development’, ‘QA’, and

‘Governance’. Of course, we should document the associated assumptions; however,

this will provide the customer the needed clarity and transparency in terms of ‘what

can be expected from the capacity bought’.

Provide clarity on ‘Threshold’ / ‘Float Capacity’, i.e. Core Team and transient team to

manage peaks and troughs

Provide clarity on Flexibility of ‘Capacity Mix’ / change, i.e. the technical skills set for

contracted capacity, and how frequently we can change it

Provide clarity on Delivery Execution model:

o One can have multiple delivery execution models across different work

packages

o Customer maintains backlog of work packages, and depending on maturing

and completeness of requirements, the delivery execution methodology is

decided

Provide clarity that there is no firm scope – Capacity is not tied to scope, rather scope

is as per available capacity

Define conditions around capacity ‘top up’; when contracted capacity is about to get

exhausted

4.1.1.1 Working – Capacity Based

There are many variants within boundaries of above stated model. For example,

We may have FP for capacity, and FP for each work package within overall capacity;

however, post completion of ‘Requirement Engineering’ for given work package.



Having work package delivered through SCRUM, yet in a FP model, either by

following ‘SCRUM – Fixed Price’ (as detailed below), or by having the price fixed only

once the ‘Requirements Engineering’ has been completed.

Any other variant / combination of Pricing and Delivery Execution model

In these approaches, the execution model does not matter, as we have contracted to

deliver scope as per contracted capacity. And, this is also the reason that we need to be

transparent in order to have the customer’s trust. We should work as a trusted advisor to

the customer, and should not be thinking of burning the contracted hours.

4.1.2 Fixing the Price for a Sprint

This is another variant within ‘Capacity Based’ model. In this model we are fixing the risk

for each sprint. What this means is that at least after first sprint (Sprint 0), the product

backlog will be known. This minimizes risk since we are taking a limited risk at a time (i.e.

for each sprint). In addition, with every sprint, the accuracy of our estimates will increase

because of familiarity to work, environment and availability of knowledge base.

The way it works is as follows:

We conduct Sprint 0 (T&M or FP)

Along with all other activities such as Requirements Engineering, Solution

Architecture, Test Strategy and Planning, Product Backlog creation, etc…. we also do

design and sprint backlog for Sprint 1

Prepare estimates for Sprint 1

Sprint 0 outcome: Product Backlog, Solution Architecture, Test Strategy and Planning,

Sprint 1 Backlog, Estimates for Sprint 1

Sprint 1 – Sprint 2 Backlog creation along with Sprint 1 development

Sprint 1 outcome – As per acceptance criteria, and estimates for Sprint 2

…

It should be noted that a new contract / WO is not signed for each sprint, rather it is just

an agreement within overall ‘Capacity Based’ contract, so it is easy and fast to execute,

and does not require any amendment or addendum to the original contract.

4.1.3 Fixing the price after Requirements Engineering

This approach is essentially finalizing the requirements upfront through T&M model,

after which we do a FP model for remaining SDLC. It can be executed either in a waterfall

approach or in an incremental or iterative way. This reduces risk since we have already



detailed the requirements, and we are doing FP for a phase where implementation

details are known, leaving very few unknowns. All we need to take care is of usual

fluctuations and dependencies.

This resembles an approach where ‘Sprint 0’ of a SCRUM is being carried out first,

though a bit in detail to finalize requirements and design, and thereafter, develop the

solution in an iterative way. It will also have a separate stabilization phase, followed by a

deployment phase at the completion of all iterations. This approach can also have

‘Stabilization’ post one or more iterations and potential release to production. Essentially,

this approach can be customized to suit customer needs, as long as they are in

agreement to leading ‘Sprint 0’ as a separate contract, though philosophy and outcomes

more or less remain same.

Though it is not SCRUM per se; however, if the customer is not bound to a pricing model

or delivery execution methodology, it does allow the customer to have their business

requirements implemented in efficient and effective way.

Even though the customer may have budget constraints, Fixed Price, will not resolve the

matter if the given scope of work cannot be completed in the given budget. As per the

construction analogy, a palatial bungalow cannot be built for $50K USD, if that is the

budget that a customer has, even if the customer asks for a fixed price for the same.

Last but not the least, to make it more appealing to customer, we can sweeten it by

having incentive based pricing. I believe, when one links his/her compensation / service

charge to a benefit accrued to a customer, the intent and trust gets built relatively easier,

if not instantly.

4.2 OPTION – 2: KNOWING / EVALUATION TO ASSESS RISK UNDER FIXED SCOPE,

DURATION AND PRICE

4.2.1 SCRUM – Fixed Price

This scenario is difficult to manage because we have fixed scope to deliver, with fixed

duration and price. One might be tempted to say, but quality is in our hands. Not

anymore, as it is given that the customer wants the best at any and every price level.

We have to fix the price and duration for something that will get defined along the

lifecycle of the project or in other words we will have progressive elaboration of

requirements, yet we need to commit on scope too (along with other two attributes).



Therefore, we have to make measure that will help in containing this ambiguity and

thereby help in assessing the risk.

First things first

1) Articulate our understanding of scope / requirements

This is important, as only this will help in bridging the gap between ‘What is required’

and ‘What has been understood’. This also helps in qualifying ‘Change’ as a ‘Change’,

because if it was not contested earlier (during initial walkthrough) it was not

considered in scope at that time, and hence will not be a topic of contention now.

We need to segregate any change or any change discussion into ‘Product Backlog’

and ‘Commercial / Financial’ discussion. This should be clarified with the customer,

i.e. how change identification will happen, and what will be our change management

process. It is important for a customer to understand that they are getting a ‘Change

Request’ because the ‘Product Backlog’ has changed, and not because of any

inefficiency at our end.

We need to have complete agreement with the customer on this understanding as

any element of disagreement will result in escalations and stress in project down the

line, not to mention the erosion of trust and ultimately the strained relationship.

It is to be noted that they are getting a value for the change, and additional cost is

not because of either delay or any inefficiency’.

In context of scrum, one may incorporate following as ‘Definition of Change’ in their

contractual agreement with customer;

1) One needs to define the scope in terms of

a. # of Epics, # of features within an Epic, and # of User Stories in a feature (also

define ‘Epic’, ‘Feature’ and ‘User Story’ and their association) – If it is not

possible to have these details, then with the help of a Domain Expert, and

Subject Matter Expert, one must detail the requirements to the extent it is

possible, and bind the scope to these details

b. The complexity breakup for each of the category, and category definition for

each category

c. If you can get down to ‘Story Points’ level that will be preferred; however,

given that it is SCRUM, and we are building the ‘Product Backlog’ in Sprint 0, I

do not think we will be able to get to this level

d. The above information (#a) should be part of ‘In Scope’. The scope is bound

by these numbers first, and that details are linked back to this scope



2) The below statements should be part of ‘Change Management’ section, with sub-

section defining ‘What is Change’. Please note that these are specific to SCRUM

working, and all other standard conditions of change that one includes in their

contractual agreement should also be included;

a. ‘Product Backlog’ defined as part of Sprint 0, should be within boundaries of

scope outlined within ‘In Scope’ section of contract

b. The detailing of ‘Sprint Backlog’ for every subsequent sprint happens in an

immediately preceding Sprint, i.e. for Sprint 1 it will be detailed in Sprint 0

itself...

c. The finalized ‘Sprint Backlog’ (prior to beginning of that sprint) will be frozen

for that sprint, and you shall sign-off on the same for given sprint, prior to

start of given sprint

d. Any change during the course of a sprint, requiring a change in ‘Sprint

Backlog’ or its operational environment, may result in following scenarios;

i. A minor change, not impacting the design, or resulting in rework, and

can be accommodated within a sprint (solely at the discretion of

‘Scrum Master’)

ii. Change, which could not be accommodated within that sprint, and

has to be scheduled within ‘Product Backlog’ after ‘Successful Change

Request’*

iii. Change, requiring abandoning of ongoing Sprint, as sprint will not be

able to meet the set objective. Thereby, initiating scheduling of

‘Change’ within ‘Product Backlog’ after ‘Successful Change Request’,

and creating additional ‘Change Request’ for budget and schedule

expended on abandoned sprint

e. ‘Product Backlog’ is subject to change within boundaries of this contract

throughout this project (until last but one ‘Development’ Sprint), and subject

to following constraints

i. The requirements / backlog items can be prioritized and re-

prioritized, except for ‘In-progress’ sprint

ii. The requirements / backlog items can be changed, provided it is

within boundaries of contracted scope, and do not impact the overall

budget and schedule for the project

f. Each change in backlog though do not require an amendment to contract;

however, redefines the scope for this contract

g. Any feedback on completed Sprint, resulting in change in functionality /

working of earlier completed sprint(s), shall be qualified as ‘Change Request’

h. Altering the structure / frequency / sequence of proposed ‘Development’ and

‘Release’ sprints

i. Any change resulting in discarding / abandoning of completed sprint, or in

progress sprint



Any deviation to above understanding (barring statements, having explicitly stated

need / condition / state for ‘Change Request’) will be qualified as ‘Change’ and shall

be managed through ‘Change Management’ process as defined in this document.

*’Successful Change Request’ – A change request created by <vendor> after impact

analysis on identified ‘Change’ and reviewed and approved by you

2) What is the possibility of doing a two / three weeks sprint to prepare a product

backlog to get required sanity in our estimates?

It is important to not think of ‘Who will fund it?’, rather think ‘what we are getting out

of it’. We get customer perspective and requirements definition from customer

directly. This along with our experience, and domain knowledge can turn this into

closer to ‘reality’ scope, thereby lending much needed accuracy to our estimates in

an ambiguous environment.

This will also lend credibility to our ‘Understanding Document’ (that we prepare post

this exercise) and the estimates that we provide to customer.

3) How important is it to have proposal walkthrough with customer?

If there are any disagreements, those must surface at this stage. So, it is important

that we have a walkthrough of our proposal and understanding with the customer.

This eliminates ambiguity arising out of interpretation and assumptions that one

would come across in the absence of the same.

Things may change depending upon whether this is a RFP response scenario, or we have

the opportunity to explore option of a short ‘Discovery’ phase. Nevertheless, we also

need to decide on our operational model, which customer should also be made aware of

during walkthrough, or through our response.

Can they share all of their requirements now?

Can those be defined in terms of user stories, or if required, will be willing to convert

those into user stories?

Why those are important or required now and throughout the lifecycle of the

project?

How can the customer verify the accuracy and completeness of user story?

What is our way of calculating the Use Case Points / Story Points?

How many Use case / Story Points that we have come up within stated scope, and

how (based on item above)?

Why all of this is required to form the basis for acceptance of sprints as well as the

final solution?



In nutshell, user stories are the corner stone of their requirements and of the project as a

whole.

Good information, but who is going to fund it? Why would client agree for this, if it is a

RFP situation? What will we do, if this information is not available?

4.2.1.1 Scenario – 1: Responding to an RFP

In order to respond to an RFP confidently, with calculated risks, we need to have

this information, otherwise, we will be shooting in the dark. Check if we can

scrape through some information from RFP, or question-answer session. If the

result is not encouraging, we have only two options:

Ask ourselves, is it a strategic account / project? What is the current state of

business (targets and bench situation)? If the answer, to first is ‘Yes’, or latter

is not affirmative, it is good to have this project, but again, not at any cost.

We can drop this project, as it does not fit into our business priorities.

Should we decide to proceed with the RFP response, we need to ensure the

following, in addition to what has already been covered above:

We document our understanding of their requirements

Bind those clearly through assumptions / constraints / dependencies / roles

and their definitions. This is required, as we need the basis to identify change

and raise ‘Change Request’.

We include ‘Proposed Solution’ (if possible), as it depicts our interest in

customer’s quest for solution.

Involve domain expert (if we have one), not only this will expedite the

activities, but will also bring substance to our ‘Understanding Document’,

estimates, and thus boost customer confidence in our abilities.

Changes have no associated cost as long as changes replace other user

stories from existing product backlog, i.e. we are not changing the size of the

product backlog

The product backlog is bound by number of user stories, story points, size

calculation of story points etc. This firms up the scope that we are signing up

for. Essentially, we are signing up for scope bound by number of story points;

as we learn our velocity to deliver those story points, we can remove the

ambiguity around scope and hence, agree to known risk exposures

It is important that we present this as our understanding of requirements / scope,

and not as a few scope items with a long list of assumptions / constraints /

dependencies. The reason being, an understanding represents the intent of an



attempt to understand the requirement, and ground work that a person / vendor

has done to come closer to customer requirements; and it is not just vendor’s

version of what he can deliver.

Alternatively, it would be better to propose an alternate to the customer in form

of the customer either providing the clarity on requirements in terms of

‘Prioritized Product Backlog’, or at minimum agreeing to or vetting out our

understanding. Either way, we secure our position to have a Fixed Price attached

to SCRUM.

This is bare minimum we have to achieve to have a Fixed Price for SCRUM

projects for given scenario. Anything less increases our risk exposure, if not

jeopardize the whole project itself.

4.2.1.2 Scenario – 2: Non RFP request and response

A discussion with client to arrive at a common understanding (as detailed in

previous scenario) needs to happen. The good part is, we have access to client

and we can propose to have some requirements sessions to nail down the scope.

Of course, it will not do away with the need to document our understanding, as

detailed in the previous scenario; however, it will result in better requirement

details, as those would have been discussed with customer to an extent.

The challenge is, ‘Who funds this activity?’ As mentioned earlier,

If the customer/engagement is strategic in nature, we should not be afraid of

making that investment, as that can be recovered over the lifecycle of the

project

Alternatively, we can propose for joint sharing for this exercise. This is usually

a one or two week investment for about one or two resources, so the cost of

investment is not prohibitive in nature

This exercise will provide us the clarity that will help us prepare reliable estimates.

Please note that in both scenarios we are minimizing our risk exposure; it is only

the means to minimize the risk that differ because of environmental constraints.

In addition to what has been explained under each scenario, we should also cover the

following aspects in our scope finalization exercise, or at least in our documentation of

understanding. We need to document:



The understanding of requirement either in terms of ‘Size and Complexity’,

with their definitions, or in terms of ‘Story Points’, with definition of Story

Point; clearly identifying the factors and slabs of increase in complexity, and

hence the Story Points

Understanding that scope in Story Points will include Technical Story Points

too, which at present can’t be determined

The environments for development, testing, UAT etc.

The configuration of the environment, i.e. OS, H/W, S/W etc.

NFRs (Scalability, User Base, Performance, Availability, Browser Compatibility,

Multi-tenancy…)

Documentation / User guides / Trainings

Entry / Exit criteria (Definition of Done) for Phase, Sprint

Roles and Responsibilities of various participating roles / stakeholders

Communication – mode, frequency, participants etc.

This exercise will make our estimates more realistic, and less susceptible to changes, as

we have considered not only the functional aspects, but non-functional as well.

Post this, it will be an estimation exercise, which would not undergo any change because

of either change in scenario or change in pricing model. The effect of change in pricing

model have been neutralized by documenting our understanding of requirements /

scope, and binding those with other elements, in form of Out of Scope, Assumptions,

Constraints etc.

5 BUSINESS BENEFITS

It opens up a seemingly unviable market segment for us, but in viable way. Although this

does have some risks; however, these risks will be assessed and controlled risks, and with the

proposed structure and preparation, it can be a profitable business proposition for us.

6 SUMMARY

It is risky to cap the price to seemingly changing scope. Seemingly, because we do fix the

scope, either through requirements, work/effort, or duration to control the risk. All

previously detailed approaches work within this principle to make those as viable delivery

models.



The risk associated with FP contract with regard to fixed scope can be mitigated through the

two options described above.

As far as ‘change’ is concerned, even in FP it is managed through rigorous ‘Change

Management’ process, as long as we are able to showcase the ‘change’ in scope via

categorizing the change into ‘Product Change’ and ‘Financial Change’.

It is important to split the change under these two categories, in order to make the customer

realize that change in price is due to change in scope of work, and not due to any

inefficiencies.

We must involve our customers in discussions to understand their needs and options that

are available to them. We need to structure our response / proposal as per guidance

detailed against each option.

It is important to have these discussions with the customer to ensure they understand the

options available to them.

It is assumed that organization has well established SCRUM practice, metrics system, and

estimation model, which give them accurate information on their velocity, productivity (per

use case point, or # of use case points) and story points. If we are attempting this in the

absence of these established factors, we will be taking an uncalculated risk.

Lastly, the principles of SCRUM execution, right from Sprint 0 to daily SCRUMS to sprint and

project conclusion do not change. It is understood that those practices will be followed

independent of in-force pricing model.

7 CALL TO ACTION

All roles involve in Pre-Sales and Delivery need to understand:

1) Stated options and sub-options in detail, i.e. their working, the constraints attached

to it, and strengths and weaknesses of each option

2) How to engage customer and persuade to have discussion around their

requirements and options available to them, instead of haggling around price or why

it cannot be done in fixed price

3) Identification of need to stated options, i.e. when to select and present the stated

option

4) What clarity we need to provide to customer with regard to option(s) and structuring

of our response



5) All of these options require transparency and trust between customer and us for it to

succeed; we need to provide clarity upfront to avoid any heartburns during delivery

6) What is the hierarchy of preference for these options from proposal perspective;

a. Explore ‘Option – 1’ first; ‘Option – 2’ should be your last option

b. Should you decide to explore ‘Option – 2’, familiarize yourself with stated

approach in detail, as it would require lot of work prior to and during a

response

7) How to structure response to minimize / mitigate the associated risk; especially for

Fixed Price, Scope and Duration option

8) When to disengage

Date post:	13-Apr-2017
Category:	Documents
Upload:	shyam-singhal
View:	102 times
Download:	0 times

SCRUM with Fixed Price-V2.0

Documents