Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Pricing with Agile projects using Scrum framework
Last Post 30 May 2014 02:46 AM by Pablo Rossi. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Prudhvi Manthena
New Member
New Member
Posts:2
Prudhvi Manthena

--
25 Feb 2014 03:07 PM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1451
    Ian Mitchell

    --
    25 Feb 2014 09:05 PM
    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.
    Prudhvi Manthena
    New Member
    New Member
    Posts:2
    Prudhvi Manthena

    --
    27 Feb 2014 12:59 PM
    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).
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1451
    Ian Mitchell

    --
    27 Feb 2014 01:24 PM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1451
    Ian Mitchell

    --
    28 Feb 2014 03:39 AM
    > 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.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:134
    Pablo Rossi

    --
    28 May 2014 03:08 PM
    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".
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1451
    Ian Mitchell

    --
    28 May 2014 11:37 PM
    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.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:134
    Pablo Rossi

    --
    29 May 2014 05:52 PM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1451
    Ian Mitchell

    --
    29 May 2014 06:26 PM
    "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."
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:134
    Pablo Rossi

    --
    30 May 2014 02:46 AM
    Hi Ian,

    Thanks for your answers! Really helpfull!
    You are not authorized to post a reply.


    Feedback