Skip to main content

Fixed Price Model in Scrum

Last post 09:26 pm May 26, 2016 by Rishi Suri
7 replies
02:22 am March 23, 2016


Any thoughts on good practices here? - I don't see clear cut directions from engagement models perspective - For example, how to approach fixed priced contracts.

I work for an IT service provider. Real product owner is not with us but from customer. Customer is interested in executing project in scrum with the fixed price engagement model. Traditionally - in FP - scope and cost are fixed. Anyone has any success stories on this?


02:33 am March 23, 2016

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.


04:13 pm March 23, 2016

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.


03:11 am March 24, 2016

@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.


08:36 am March 24, 2016

@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.


09:33 am March 24, 2016

> @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.


06:03 pm March 24, 2016

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.


09:26 pm May 26, 2016

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.