Without even to get into the very fundamentals of Scrum, a quick thought about the framework makes the thinker focus on three important aspects:
- 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”.
- 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.
- 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).
It is not as difficult as it sounds.
Yes, the difference is significant, let us examine why.
- 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.
- 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.
- 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 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.