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.