Agile Blog Sponsored By  Agile Sponsor    Agile Sponsor   

 

 



Scrum and Fixed Bid Projects


Written by  Bhardwaj Velamakanni | 25 July 2011
E-mail PDF

One of the primary concerns of the software practitioners about the Scrum framework(or Agile methods in general) is its adaptive nature as opposed to the conventional prescriptive approaches. The common question that is usually thrown around is “How can you estimate and present a bid if you are Agile? How does it work if the customer expects a fixed bid?” This article tries to answer that question in the few paragraphs thatfollow.

Without even to get into the very fundamentals of Scrum, a quick thought about the framework makes the thinker focus on three important aspects:

  1. Time-box: The projects based on the Scrum framework are time-boxed whichmeans that the period of activity is fixed, usually one to four weeks for a sprint andone to three months for a release. What this means is that the development team tells the customer team “We will give you something at the end of this period”.
  2. Scope negotiation, not time: As the time is fixed and quality can never be compromised up on, the only point of negotiation here is scope. So, instead of buying more time to address the entire scope scheduled, the agile teams reduce the scope to fit to the schedule in the event of their inability to complete everything that they said they would.
  3. Prioritization: All the items that are being developed using the Scrum items are ranked as per their value and worked upon in the same order. This means that theitems with the highest importance are attempted first and in case the team is bound tomiss some items, they are usually from the bottom of the list, i.e., the items of lower value (Unless, of course the team misses a huge part of its target).
Now, coming to the bidding problem, the ideal situation is that the team bids for the project on a Time & Material basis, in order to accommodate the changes in an efficient manner. However, many customers prefer to know the costs ahead so that they can plan their budget better. So, the challenge is to find a way to fixed-bid a Scrum project.

It is not as difficult as it sounds.

Scrum Fixed Price Projects
Yes, the difference is significant, let us examine why.

  1. The time is fixed and so is the cost. So the customer would know exactly what they are spending. This helps them plan their budget better.
  2. Negotiation is on the basis of scope. So, even in case of any slippage, the customer and the development teams do meet their deadlines, albeit with limited scope. The release happens as planned on the committed date and this helps the team enormously since there is “certainty” as far as the release is concerned.
  3. Cutting the scope down!!. History tells us that a lot more than half of the features required upfront are not used. This is mainly because the product owners tend to club “Nice to have” features with “Must have” features. Since the Agile projects get executed on a priority basis, the teams always complete the features with highest value first so that in case they miss some feature, that usually falls within the range of a feature that is seldom used and the product owner could even decide not to implement that feature in the near future.
The comparison is clear - in the traditional style, the development team gives everything to the customer with additional cost and on the Agile way, the customer getsthe minimum viable product on time. What is better?

The bidding approach is not difficult either - Once the customer lets the scope out, the development team could do a quick vision planning that results in “Rough order of magnitude” estimates. This ball park estimate gives the teams the initial direction and the decision making advisory.

Then the team would plan the releases with story points. This should not take muchtime since it is not really detailed and the estimates are in terms of story points. Once the story point range is known, the team would match its velocity with the story point scope and then presents its bid, based on the number of releases required to deliver the features requested by the customer. The team may also advise the customer about thefeatures that may not add value to the customer, there by leading to savings.

Then the interesting part - if the scope changes during the course of the development activity, which usually would, the changes are handled within the time-box. The scope changes, not the estimates. If the requested (new) feature is of high priority, then the feature(s) matching the effort needed to develop the new feature would go out to the next release. So, the time is preserved and the value of the release is enhanced too - a win-win!

To summarize the concept, in a fixed bid environment, the team commits to a “fixed quantity” of features that would add maximum value to the customer. The set of features may change, depending on the evolving needs of the customer. This is in contrast with the traditional methods that make the team commit to a fixed set of features.

Scope creep in a Traditional Project
Origianl After Change
Feature 1 Feature 1
Feature 2 Feature 2
Feature 3 Feature 3
...... ......
...... ......
Feature n Feature n
Feature n+1

Additional time for Feature n+1  
Scope creep in an Agile Project
Origianl                  After Change
Feature 1 Feature 1
Feature 2 Feature 2
Feature 3 Feature n+1 ((Feature7
pushed back to accommodate
high priority 
n+1))
Release 1 Complete
...... ......
Feature n Feature n
Feature 3 Feature 7
Additional time for Feature n+1

RSS  Subscribe To Our Feeds       Stumble upon  Subscribe By Email


Bhardwaj Velamakanni

Bhardwaj Velamakanni

Bhardwaj Velamakanni (CSP, SAFe - SPC, PMP, PMI-ACP, Six Sigma Black Belt, D Sc) is an Agile Coach, Scrum Master and was a senior Project/Program/Delivery Manager in IT/Software development and played multiple roles as Organizational Head/Program Manager/Project Manager/Scrum Master, Agile/Scrum Coach, Software Architect, Business analyst, C++ and Java Developer/Lead and Research Fellow.

blog comments powered by Disqus