Fixed Price Model in Scrum

If you know your costs per sprint, you can offer a certain number of sprints for a given price. It's up to the PO to order the scope of work for the best value.

We made good experience with a FP contract. We split up the the whole project into smaller milestones. Each milestone consisted of a fixed amount of Sprints and contained the general goals. The customer ordered a certain amount of milestones in advance to reduce the risk on our side.

At first the customer's PO was quite stuck on the predefined milestone goals and we were not very agile. But after a while the customer trusted us to produce high quality code. So the PO started to "interpret" the defined milestone goals on demand, i.e. we always met the milestone goals because they were defined in detail at the end of a milestone, when the development work was already done. So at the end we still had a FP model on paper but in reality we had a ScrumTeam that the customer booked for a certain period of time. The customer got what he really needed and we could focus on development and not on negotiations of milestone goals.

@Ian, Michael: How do you manage to get an estimation how many sprints it will take the team?

Some thoughts on this:
- If you involve the team (what I would prefer) you need a breakdown into epics and stories inclunding an estimation before you can offer a fixed price (e.g. based on the team velocity).
- Not involving the team would mean to pre-commit for the team, even if you add an buffer on top.

@Joerg:
We made an initial estimation based on an initial Product Backlog that consisted mostly of Epics to give the customer an idea of how much time and budget was needed. We didn't complete all items from the initial Product Backlog because during development the PO identified more important tasks and updated the Product Backlog accordingly.

> @Ian, Michael: How do you manage to get an estimation how many sprints it will take the team?
>
> Some thoughts on this:
> - If you involve the team (what I would prefer) you need a breakdown into epics and stories
> inclunding an estimation before you can offer a fixed price (e.g. based on the team velocity).

To be precise, the Development Team will not need that full breakdown just in order to start work. Scrum does not stipulate any such preconditions for sprinting to begin. However, the Product Owner and stakeholders might need an estimate of how many sprints, and at what cost, are likely to be needed in order to complete a given articulation of scope.

If the Development Team are to provide the PO with that estimate, they will need:
- sufficient understanding of the work in scope, so that reasonable estimates can be made
- the qualities required for the work to be Done, as per the Definition of Done, and
- the velocity or throughput they are likely to demonstrate.

> - Not involving the team would mean to pre-commit for the team, even if you add an buffer on top.

That's right. They must be involved. In Scrum, the Development Team are responsible for any forecast made of the work they are expected to do.

I'm with Ian. FP project = fixed number of sprints. Why? b/c each sprint costs the same; # days per sprint X cost of scrum team per day. So, extra effort should be made to make sure PO (customer in this case) is clear on the point of a fixed # of sprints, therefore PO needs to make sure PB is the best it can be at the start of each sprint planning session.

Make sure the dev team is clear about the fixed number of sprints and therefore, should be hyper-transparent during all events.

While not specific to Scrum, I find it worthwhile to pay more attention to "risk adjusting" the sprint plan (in planning event) when working on FP project, where there is more "margin" versus T&M projects. On FP, all must appreciate that each increment must fulfill the sprint goal, unless PO is willing to give a free pass. B/C the PO may demand extra sprints at no additional cost to make up for sprints that did not meed the sprint goal.

Finally, from the start, make sure there is a very transparent visual that shows budget consumed vs. budget remaining; # PBIs completed vs. # PBIs remaining, grouped by theme/epic, if appropriate. Actual vs. planned. Basically, a release burn up with budget summary added.

The approach suggested by @Ian and @Scott does give a good approach for handling FP projects. It does give a clear picture of what the output will be in that amount.