Wednesday, February 17, 2010

Bidding for Agile SCRUM projects

I received a call from one of my friend asking if I had any idea about how to decide the cost of a project if it needs to be used for bidding for an Agile SCRUM kind of a project. I was puzzled at the thought at that very moment. I directed him to one of my friend who is an expert in SCRUM.

But, later I searched about this on internet and found few good posts pointing to some solutions and thoughts regarding the same, as following --

....the price for the project was fixed, but the features themselves were negotiable according to rules agreed to in the contract. The features were broken down, and time was tracked on each feature. Whenever the development team took longer than anticipated, the client removed scope. Conversely, when the development team finished a feature early, scope was added. In order to add incentive, effort added or removed was discounted by 50%. For example, if the development team finished 2 days early, only 1 day of extra scope was added. On the other hand, if the team finished 2 days late, the client only removed 1 day of scope. The contract actually specified the rules by which scope was added or removed.....

More detail at --

Additionally, TDD, test coverage reports bundled with CI are key to achieve the required quality and agility during the project execution.


pat said...

Interesting... thanks for bringing this up, Riju. I'm intrigued by the role CI might play in the contract for an agile project. Is it too technical for a client to be exposed to? And should clients just assume for an agile project the team has implemented CI and good code coverage? ... or should the amount and type of testing be explained to the client or possibly even tied to the contract?

Riju Kansal said...

hmmm. Thanks for your comment Pat. You are correct in saying business need not care about CI / testing. But I am pretty sure that the team will not be able to achieve success in delivering quality without CI and TDD. There should be some way to mandate the use of both. Or we assume the team is mature enough to not skip it.

Moreover, the dev team and customer are kind of partners in building the application / solution. So I think there is less harm in making the customer aware of the practices which are inevitable to achieve quality.

What say?