Agile Contracting: A Story-Point Billing Model

10 April 2013

Prabhakar Gumma


Contracting and billing models have always been a point of debate in the IT world. Fixed price or time and material? Which one to select? Both models have been criticized for their biased features toward vendor or customer, but this is more significant in the Agile world, since the Agile framework consists of frequent delivery of value-added features in shorter iterations. In such scenarios, the customer expects a billing model to be based on the value of delivery, while the supplier would expect a low-risk/high-profit model. Both customer and supplier are right on their own terms, since they have their own goals to achieve within a given time frame.

Past trends have indicated customer or supplier dissatisfaction over the existing contracting model in Agile. I've seen instances of a customer taking advantage of the contracting fixed-price model and pushing additional requirements under the cover of the Agile framework. One of the biggest disadvantages of using the fixed-price contracting model in Agile delivery is limiting the adoption of the Agile philosophy of embracing and welcoming changes. However, I've also seen instances when use of the time-and-material model brought genuine customer fear of overcharging by the supplier against value delivered with no time-frame commitment. In such scenarios, the supplier team doesn't collaborate with business to deliver value in shorter cycles.

The need of the hour is an Agile contracting model with win-win features for both customer and supplier. The customer would expect the following features to be in such a model:

  • High value delivered at lower cost
  • Pay per delivery
  • Short and frequent delivery cycles
  • Optimum quality

All of those customer expectations are legitimate if we put ourselves in their shoes. Similarly, suppliers also expect certain features in the model:

  • Improved profit margin and revenue
  • Covered risk of embracing and welcoming change in the billing model
  • High team morale
  • Customer satisfaction

In the past, we've seen instances of the two wish lists being fulfilled unsuccessfully because of bringing in clauses of requirement-changes management in fixed-price models. Such clauses are open to judgment, and suppliers and customers interpret them differently during execution.

The story-point billing model

Let me discuss a model that takes care of both customer and supplier — and is feasible. The term "story point" in Agile isn't new, and it's well known by most people involved. Meanwhile, certain terms in contracting models are not known to every team member. A story point is the relative size of a user story, decided by the team based on a triangulation wall created by the team. The model is based on the fact that the customer is billed only for the story points delivered within an iteration. To be more specific, the term "delivered" means "accepted by the product owner." For example, if in an iteration the team committed 20 story points but delivered 15, and 10 were accepted by the product owner after demo sessions, then the customer should be billed against only 10 story points.

For such a model to work, a few ground rules need to be clearly formulated and documented:

  • Formation of a triangulation wall for estimation
  • Story point and dollar conversion
  • Iteration scope

Let's start with the first point of the triangulation wall for estimation. Since the billing model is based on story points, a strong basis of determining story points is needed before implementing this model. A wall would be based on a typical group of generic tasks for a story in a specific technology and domain. Let's take an example: Consider business intelligence technology, where a typical user need is to build a report from two different source systems. Such a story would require bringing in data from the two source systems and then generating a report. A simple user story of one story point would be bringing data from one source system and generating three records in a report. Relative sizing would involve complexities of more source systems and the fields required to be generated for the report. Though I fully understand and agree that a user story should be written from the user's perspective, this example is taken from a team's perspective, to map a potential user story to a triangulation wall line item.

Such triangulations walls need to be generated up front by the team and shared with the customer so that team and customer agree on a transparent, evolving triangulation wall as a basis of determining story points. Such triangulation walls can be used as guidelines by the team during release and sprint planning exercises to determine the story points for user stories. However, the assumption here is that the same team should have also been involved in formulating the triangulation wall.

Once a triangulation wall is established and implemented, we need some time to actually calculate the cost of developing a story point. This time period can be considered a pilot phase for implementing the story-point billing model, and during such a phase the customer can be billed based on time and material. However, this phase should be timeboxed and agreed upon up front. The cost of developing a story point during this phase can be determined by actual story points accepted and dollars billed during the phase on an iteration basis. Once the cost of developing one story point is determined and agreed upon, then the billing model can be moved from time and material to story point.

However, implementing a model like this requires strong team and customer commitment to the Agile philosophy. While the team welcomes and embraces changes, such changes should follow appropriate paths before getting into a sprint scope. The team and customer should agree on the sprint scope beforehand, during the sprint planning meeting. While business (the customer) needs to ensure that all stories scoped for a sprint have been defined with acceptance criteria, the team needs to ensure that all dependencies have been identified and met for the stories scoped for the sprint. Any changes within the sprint would be updated in the product backlog and reprioritized.

The applicability of the model

I may seem to be against a fixed-price or a time-and-material model in the Agile context, but I believe that industry maturity in understanding the Agile philosophy varies greatly. The applicability of Agile becomes more trivial in the service industry, where business is customer-driven and the team is supplier-driven. Under such circumstances, contracting models not only bind customer and supplier together to achieve a common goal but also leave little room for deviation from core Agile practices. While frequent and early delivery is helpful to business for early time to market, it's also helpful to the supplier for continuous revenue generation. Similarly, to bill only on accepted story points enforces a good-quality product being developed at the supplier end by ensuring technical excellence.

While there is no reason to believe that such models cannot be applied to all Agile development scenarios, considering the complexity involved in deriving a triangulation wall and story-point dollar conversion, I would suggest that the applicability of this model would be more beneficial in the following scenarios:

  • New product development (evolving requirements)
  • First-time customer-supplier partnership using Agile development
  • An Agile program with multiple parallel projects


The need of the hour is addressed by implementing this model. While the customer is happy paying what he believes is based on the value of delivery, the supplier's concerns are also addressed by the potential scope of generating more revenue by delivering more value in a shorter time period. Also, such a model ensures continuous customer satisfaction and a healthy supplier-customer relationship. However, we need to ensure that the team's motivation level is not compromised by extended working hours in order to deliver more value.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 1 (1 ratings)


Srinath Chandrasekharan, CSP,CSM, 4/10/2013 5:47:50 AM
Good article. One point where I have a slight difference of thought is that "First-time customer-supplier partnership using Agile development". I would believe that this would be more likely in a mature relationship between the customer and supplier. In the service industry many projects are worn though RFP's and to have such a contract for a new relationship seems difficult. Can you share your thoughts / experience on this.
Srinath Ramakrishnan, CSP,CSM,CSPO, 4/11/2013 5:30:52 AM
Nice article. I agree with Srinath Chandrasekharan when he says that there has to be a mature relationship between the customer and the supplier to make this model work. I also see a potential conflict between the two in the formation of triangulation wall for estimation and story point conversion to dollar value. Could you perhaps shed more light on this based on your experience?
Michael Brashier, CSM,CSPO, 4/11/2013 11:18:29 AM
Interesting idea. I do see a possibility of conflict with management pushing a team to increase the size of stories (to make more money) and the customer pushing a team to lower the story size (to decrease cost). How do you avoid interference with the team's sizing?
Ram Srinivasan, PMP, Professional Coach, CST,CSP,CSM,CSPO,REP, 4/11/2013 9:07:48 PM
Prabhakar - Your article does provide interesting perspectives. I have a few questions

1. I have the same question as Michael- What checks and balances do you have to prevent the vendor team from inflating the story points (after the pilot) and the client/customer to push the team to lower the estimates? I assume you have the team from only one vendor. If team comprises of people from the vendor team and customer (they want to have some insight into what team is doing, lets just say) it complicates the challenge.

2. I still do not see how this solves the fixed bid issue. Only now you have the team committing to a features within a given timeline and isn't it obvious that they will lose money if customer does not accept stories. What will be the repercussions to the vendor team (from their managers) if fewer stories get accepted? Have you thought about it?

3. You never talk about quality. Just because the customer accepts the story does not mean that best possible architecture/technical practices and followed and the code has good quality. I can only see people taking the easy route out, forget quality, get more features done and make more $$

4. I think the vendor now is taking more risk. If no stories get accepted, they would have already spent $$ (salary) on their employees without making any money that sprint. Probably something like ($x / person / sprint + %y /person/sprint) can address this challenge

5. User stories are one type of artifacts. What about enhancements which cannot be estimated as story points? And escaped bugs which carry over from previous sprints?

6. Strictly speaking, this model will essentially eliminate zero point stories, but you still can have a minimum $ amount for zero point stories.

7. Reliable estimates (by the team) can only be given if the vendor team is stable. If people are replaced, estimates, usually will go up as tactical knowledge will be lost. Client indirectly end up paying (in terms of increased estimates) for this.

Just my observations and comments. Good article though.
Sundaresan Subramaniam, CSM, 4/11/2013 10:39:09 PM
Nice innovative thought around how we can consider story point based cost model. Adding to the thought we should look into benchmark cost per story point across technologies and platforms like how we have for FP point estimation benchmarks for different technologies.
Another pointer could be what is the minimum story point a team should deliver like 6 user stories per week for 5 member team.-Sundar
Good article Prabhakar. "Billing based on story points accepted by Product Owner" is definitely a new idea as compared to existing TnM and Fixed Price contract. We need to accept the fact that today no existing billing model can satisfy needs of Agile project or create a win-win situation for both Supplier and Customer.
Jeetendra Gore, CSM, 4/12/2013 10:32:04 AM
Good article !
Tim Murry, CSM, 4/12/2013 12:53:38 PM
Very interesting ideas. How about using the Triangulation Wall idea for a very different purpose - standardizing story point estimation across teams and comparing productivity levels?
Mudduluru Gajendra Varma, CSM, 4/14/2013 3:03:20 AM
Good article. But my idea is at least we need to run few sprints with time and material format to get settle down the resource velocity and familiarity with customer requirements then turn it into the story point billing. Otherwise vendor will loose for first few sprints and impacting resource performance by increasing the pressure by the management.
Prabhakar Gumma, CSP,CSM, 4/15/2013 11:33:05 AM
Thanks for our comments. I agree to some of the points raised. The key to the success of this model is the triangulation wall. While the implementation of such model needs to be done in a phased approach with initial sprints spent towards stabilizng the wall. Triangulation wall should be constructed based on mutual agreement of the technical team from supplier and customer.
Vikas Jain, CSM,CSPO, 4/16/2013 1:50:05 AM
Good article Prabhakar. But can we say that story point billing is kind of time and material based
Michael Swansegar, CSPO, 4/23/2014 9:36:01 AM
This works primarily in favor of a managed service provider. Points are subjective and based on a number of factors but ultimately decided by the delivery team. The business has a voice but the decision is at the delivery team layer unless you don't want them to have a mature velocity of their own. Since the delivery team is the managed service provider, this puts the leverage in their hands. Velocity and capacity are two different things and this clouds the issue by putting them together. Unfortunately, the triangulation wall stays up and is just a formula of points to hours thus undermining true velocity measurements. The triangulation wall or anchor story (Mike Cohn's estimation book) are only used to start the team off on story points sizing, not to keep them in some corner. If that's the case, you might as well use hours for payment. I have yet to see laws in the court room talking about overtime payments to employees to be based on points. The courts would be flooded with cases because story points are subjective to perception. What I value is not what you value, what I consider risky may not be risky to you...however if I am the delivery team, I will bill you based on my risk projection in a story point instead of the actual work I performed. That is almost unethical. Even lawyers keep track of actual hours for a reason, it is what you bill against. That is different than talking to a client about risk, doubt and complexity. The same is true with software.

You must Login or Signup to comment.