This is the one question Agile teams are always asking each other, and I see many questions in blogs related to it as well. How do we bid on a fixed-price project? It's a question I asked myself for a long time. Finally I've found a solution — or at least a work-around to get the project estimate before bidding on the project itself.
It's risky to commit to a fixed-price project. Those who follow Agile methods are generally reluctant to accept such projects, but there are some situations (maybe a management push where management is premature in Agile, for instance) when we are compelled to commit to them. If the team has a proven velocity in this domain, then it's fairly easy to find out the estimate and schedule. The risk becomes higher when the team doesn't have a proven velocity in the specific project domain.
When the team has no sprint velocity in a specific domain
Let's assume an Agile team is already in place. When this team gets an offer for a project with fixed price, the biggest challenge is to find out a list of features. Most customers can give a high-level feature list (epics); then the combination of team, marketing person, and domain expert can find out the estimate.
The marketing person and domain expert can act as the product owner, and the team helps them estimate the project. The marketing person and domain expert sit with the team and elaborate on the high-level feature list, splitting its elements into low-level features or a user stories list. They can conduct meetings and discussions with the client and fine-tune the low-level feature list. This will ensure that the team can estimate the project efficiently, since it can clarify any questions with the domain expert and sales person.
The estimation is done in story points (relative estimation), and team has to convert those story points into hours. Once we find out the hours estimate, then we can arrive at the cost of the project. How we can find out the estimated project hours? One solution is to run a sample sprint of one week, selecting a few features from the product backlog. If the team completes 50 story points in 250 hours, then each story point costs 250/50 = 5 hours.
So if we estimate, overall, 1,000 story points, then the estimate of hours will be 5 x 1,000 = 5,000 hours. The team has to decide on the DoD (definition of done) before coming to this estimation. If we're billing $X for each man-hour, then the cost will be 5,000 x $X.
If our estimation goes beyond the fixed price of the project, then we have to check with the customer. We need to push the customer to find out the major features (we can use the MoSCoW method or some other criteria). Run estimates for the selected features again, and find the cost. Repeat these steps until the project cost comes under the project quote amount. The team should commit only those features that it can complete within this project cost. If the customer agrees with those features, then we can go ahead with project. Otherwise, say, "No."
Once the project estimation is over, then the team can concentrate on committing the schedule. We sometimes conduct a sample sprint for estimating the project. This way we'll get a rough velocity of the team and, based on that, we can set a schedule for the entire project. When we submit a schedule, we give three: bad, normal, and good. This will give us protection on the schedule in case something goes beyond expectations.
Changes in the features
There may be changes in the features, and there will be continuous juggling with the product backlog. But the team should be always conscious of the agreed-on project cost before committing any changes. Changes should be allowed in Agile, but they need to be limited by cost. If these changes are giving real value to the customer, and the customer also agrees to change priorities (maybe some less-desired features are pushed down the list or thrown out of the backlog, for example), then the product backlog can change. But those types of negotiation have to be conducted by the PO with the customer.
Teams with measured sprint velocity in a project domain
Estimation is comfortable in these cases, since we know our team velocity in the specific project domain. Here the team can sit with the product owner and estimate the features. This estimation helps decide the feasibility of doing the project. The person acting as product owner can interact with the customer and find out the most desired features. If the customer isn't aware of the financial value of the features, the product owner can help determine them, since he or she already has experience doing similar projects. Experience helps in this situation.
The risk of feature changes
As we're following the Agile approach, we don't just say no to any type of changes in the selected features. Here the level of experience in handling projects comes into the picture. I've seen many teams put some buffer time into the estimation to accommodate these changes. Some people can argue against using that practice in Agile, since Agile is about transparency between the customer and the team. But I agree with some level of time buffering — especially in a fixed-budget project, where any extra cost will make the customer panic.