Skip to main content

Scrum Forum

Pricing with Agile projects using Scrum framework

Last post 03:46 am May 30, 2014
by Anonymous
9 replies
04:07 pm February 25, 2014

We have different kind of pricing models. In case of T&M (Time & Material) pricing is based on number of hours, whereas in FB (Fixed Bid) the pricing is done based on number of hours estimated. Irrespective of the pricing model, the cost be calculated as rate per hour. Example: Cost for 100 hours is 1000$ (10$ per hour).

With Scrum, my understanding is the pricing is based on the complexity of story point (or features). Ex: small - 5$, medium - 10$ and complex - 20$.

Is my understanding correct? How does the pricing happen for Agile projects?

10:05 pm February 25, 2014

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.

01:59 pm February 27, 2014

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

02:24 pm February 27, 2014

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.

04:39 am February 28, 2014

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

04:08 pm May 28, 2014

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

12:37 am May 29, 2014

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.

06:52 pm May 29, 2014

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?

07:26 pm May 29, 2014

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

03:46 am May 30, 2014

Hi Ian,

Thanks for your answers! Really helpfull!