Pricing with Agile projects using Scrum framework

Scrum projects can be funded either by Time & Materials or Fixed Bid. This allows funding to be given either incrementally, sprint by sprint, or for a fixed number of sprints to br purchased.

Story points should not be commoditized under any circumstances. Value lies in delivery, not points.

Thanks for the response, Ian! Let me try if I understood correctly with an example. I (as a Client) wanted to have an invoice application. The vendor (business partner) has come up with an estimation of 10 sprints. If I go with Fixed Price contract, the funding has to be for 10 sprints, irrespective of the development takes more or less sprints. If I go with Time & Material, it is straight forward that funding has to be for each sprint. In summary, the funding will be made per sprint (in Agile projects), as against to per hour/unit/day (in non-Agile projects).

That's basically right. In an agile contract you should pay for the value delivered. It's best to do this sprint by sprint in order to minimise any financial risk.

If a client wishes to pay for multiple sprints up front, thereby securing the services of the supplier for that period, then they may do so. It's wisest to see the purchase in those terms rather than as the time forecast to complete the product, since the suppliers estimate could be substantially out. You've effectively booked the supplier for a number of iterations, during which scope can be clarified and reprioritised and maximum value delivered.

> the suppliers estimate could be substantially out

One important thing to note...if the supplier asks the Development Team to make this estimate, it would be contrary to Scrum practice. This is because the ability of a Development Team to make a forecast is constrained to the Sprint Backlog. They are not in a position to make any forecasts regarding the Product Backlog since they do not own it.

What they *can* do is to size that backlog, assuming they are willing and qualified to, and provide their established velocity. In other words they can supply essential data to stakeholders, but they can't make a forecast regarding what will be delivered or by what date. In Scrum it would be the responsibility of the Product Owner to make any such forecasts using the data available.

Hi Ian,

Are we talking about a fixed price per sprint? Or perhaps fixed price per deliverable?

I'm having a hard time understanding how this can be turned into a salesmodel. Because essentially you'll be telling the client "a sprint cost x dollar and the team decide how much items goes into the sprint".

The price of a sprint should be known, because in Scrum that's the smallest unit of business risk you can pay for. You can't really pay a team for less than that.

Knowing the price of a sprint allows either a fixed number of sprints to be purchased or for funding to be applied incrementally, sprint by sprint. Incremental funding is best because it limits risk to one sprint.

Paying up front for a deliverable is still supported though, because X number of sprints may be purchased. The important thing to realize is that the client isn't paying for what is initially on a sized Product Backlog, since it will change throughout development. That's a good thing because it gives a Product Owner the ability to change his or her mind about priorities, and on what each increment should deliver.

I really like the idea of fix price per sprint.

Lets say im the client and I said the following:

Fix price per sprint? So i pay the team x amount and there is no guranthee what i will get back? Perhaps the team forecasted 5 items and only delivered one. I would not be happy to pay for 1 deliverable.

What would your response be?

"For X amount you can expect to get Y sprint increments. The content of each of these is negotiable and can be subject to prioritization and revision by your representative Product Owner. You no longer have to pay for Change Requests as the expected backlog for each sprint can be negotiated at any time prior to its commencement. You can also expect an early ROI as each increment should be potentially releasable.

"If you don't want to stump up so much cash first, you can pay incrementally sprint-by-sprint instead. If you aren't satisfied you can terminate the agreement at any time, thereby limiting your risk to one sprint's worth of funding."

Hi Ian,

Thanks for your answers! Really helpfull!

Hi Team,

Few quest from my side.

Question 1: If have go with fixed pricing model for each sprint, how do I arrive at the cost of each sprint? 

Question 2: What is the case when there are mutiple technologies in scope and each scrum team have different skillsets?

Srinath - I've never done this myself, but could you calculate it based on who is in the team?

Number of team members * Daily rate * Days in sprint

You could break it down per team member if they have different daily rates.

For example, for a team with 7 people, the cost could be

7 people * $500 daily rate * 10 days = $35,000

Are we all effectively saying that Agile contracts only work in this "capacity model", where the vendor is just supplying "heads" as part of the development teams? I am yet to see a customer who would agree to pay for x number of Sprints without getting a commitment on the outcome delivered. We cannot tell the customer, hey the outcome depends on you because the Product Owner should help us prioritize the backlog.

I am yet to see a customer who would agree to pay for x number of Sprints without getting a commitment on the outcome delivered

They are getting a commitment on the outcome delivered. Every Sprint. That's what they're paying for. 

If longer term certainty can be provided, that's fantastic. Plan the work out, contract it, and do it. No innovation runway is required, so you don't need Sprints and you don't need Scrum.