Fixed Price Contracts - Doing it Agile way

The basic principle of Agile Methodology is to develop product in small increments based on the regular feedback received at the end of each sprint (2-4 weeks). The feedback often results into change of requirement/new requirement, Agile processes harness change for the customer's competitive advantage. As the project’s scope can be of dynamic in nature, it is advisable to go for “Time and Material” type of contract. Unfortunately, due to several budget constraints clients may still want to opt for “Fixed Bid” one(by the way - Fixed price RFP's are a buyer's way of displaying his/her own company's internal weakness. As long as service providers continue to chase after these thorny bones the market will continue to find providers willing to sacrifice their people for the sake of meeting revenue targets). In “Fixed Price” type of contract – time, scope and cost remain constant.

So is it even possible to work in a fixed bid Agile mode?
If yes ,how to provide the estimates?

Once the Agile mindset and the thinking behind scrum is explained to the client, the need or demand for a fixed bid price is dropped in favor of the client, him being able to continuously “direct” the product. Though if it still has to be a fixed bid assignment, following are a few things that can be done to have an effective estimation:

- Move from fixed scope to fixed size/budget: Scope, time and costs are three constraints of the “Project Management Triangle” where one side of the triangle cannot be changed without affecting the others. To leverage Agile the triangle has to be tweaked to replace fixed scope by fixed size.



-Get the Product Backlog ready: List down the high level features, involve the PO and customer to refine them as user stories.

-Estimate the Backlog in terms of SP: Use Ranges to get an estimate, get the team involved for a couple of hours every day. So considering if the product backlog has 200 user stories,team can figure out a range,lets assume it as 1000-1200 SP.
-Estimate the cost to cover the SP: Based on team's past experience or by running a demo sprint , total SP covered in a sprint can be calculated(Velocity) .For example , a team's velocity is 30 SP in a 2 week sprint which is equal to 3 SP/day = 3SP/6hours=0.5 SP/hour. Dividing the calculated SP range by the SP/hour ,i.e. 1000/0.5(2000) - 1200/0.5(2400) . So the hour range comes to be 2000 Hours-2400 Hours . Multiply it by per hour billing ($Z)to get the estimated range of cost , i.e. 2000$Z - 2400$Z .
-MoSCoW Estimation : Use MoSCoW estimation (Must Have, Should Have, Could Have , Wont have) to bring the features under estimated cost , in case the cost is going over the fixed one.
-Exchange Model: Requirement changes to be handled carefully as it may affect the agreed cost. Prioritization should be done keeping the features (that may give real value to the customer) and the cost (it may incur to the project) in mind. The requirements can be dynamic in nature so the existing user story can be replaced by new ones of same size. It is also called as an “Exchange Model”. The overall size of the dynamic product backlog remains same however the Product Owner (PO) can introduce new user stories that are high on business values by exchanging them with the existing ones of the similar size.

Agile methodology is often considered as a misfit for fixed price contracts as the scope is perceived to be one of the constraint. With the help of this post we have just tried finding a few ways to deal with it , hope it helps.