How does pricing work for agile contracts?

When it comes to pricing for software contracts, two opposite interests collide: the contractor wants to achieve the highest hourly rate for the project possible. On the other hand, the client wants to keep project costs as low as possible and get the maximum benefit with their budget. Of course, this is only the first, contractual overview, because the reality does not always look like this.

Nevertheless, we want to find a contractual model that takes these interests into account and regards them on paper equally. We show you possible pitfalls as well as an alternative solution approach from which both parties in an agile IT project benefit.

Risk sharing: A key aspect aspect of software contracts

When working together in agile projects, the risk is inevitable for both parties. Because even if a detailed briefing takes place and requirements appear to be clear, changes can and should be allowed to occur during the implementation. An agile process model is used to limit this risk.

A substantial risk that can occur is that implementing a user story may take significantly longer than planned. It is, therefore, important to consider the possibility of risk-sharing before signing a software contract. After all, the contractor and the client bear a different share of the risk, depending on on their contract.

We will show how the risk distribution works, using two common pricing models (T&M or price per team hour and price per story point):

Price per team hour

A widely used model is billing based on team hours.. This is a classic T&M procedure where the entire risk lies on the client’s side. He pays the contractor for hours worked, regardless of the result of the work performed.

Price per Story Point

In this model, the contractor gets paid upon completion of a story point. This should motivate the contractor’s team to work efficiently. The risk with this model clearly lies on the contractor.If no completed story points are delivered, there will be no payment made.The risk which clearly remains with the client, is that they don’t have a working software, meaning the “time to market” suffers as a result.

As you can easily see these two models have a major disadvantage: they distribute the financial risk for the collaboration very unevenly. The risk lies mainly with one party.

But there is another way.In the video made for this blogpost, TechTalk’s Agile Coach Richard Brenner explains the difference in detail and presents an alternative approach.

Combining client’s and contractor

TechTalk has been working on solving this problem for many years. In order to spread the risk equally among both parties, we have developed a model that combines the two methods: price per team hour and price per story point.

Our model, “Pay per Story Point and Hour,” splits the project risks between contractor and client by combining the following components:

  1. Price per Story Point: fixed-price share per delivered functional unit, according to the solution complexity assumed at the beginning
  2. Reduced Price per Story Point: reduced fixed price per delivered functional unit, for example, if an unforeseen story point is added
  3. Price per Team Hour: Variable price share per actually performed contractor team hour.

Let’s look at a concrete example to understand this model and its effects in different scenarios. 

Calculation example for the combined TechTalk model

Let’s make the following assumptions for this example:

  • Experience shows that the effort for a story point for a team in a project is 8 hours. 
  • The price for a team hour is 100 EUR. 

Thus, the calculated sales price for a story point is 800 EUR (8 * 100 EUR per hour). 

This is divided into:

  • A fixed share of 400 EUR per Story Point
  • A variable share of 50 EUR/hour (800 EUR – 400 EUR / 8 hours per story point)

In addition, a reduced price for an unforeseen increase in complexity is set at 100 EUR per story point.

In our example, we want to split the share equally. The figure below shows the effects in comparison to a billing based exclusively on story points or hours.. When invoicing exclusively by story points or hours, the full risk always lives with one of the contract parties. This is not the case with the combined model. In this model, the risk is shared.

How can the risk be divided?

In the next step, let’s take a look at how this splitting affects three different scenarios. Let’s assume that the total number of Story Points is 1,000.

1st scenario: Exact adherence to the plan

The following services were rendered: 

  • 1,000 Story Points
  • 8,.000 hours

These were accounted for as follows:

  • 1,000 Story Points * 400 EUR = 400,000 EUR
  • 8,000 hours * 50 EUR = 400.000 EUR

This results in total costs of 800,000 EUR and an average selling price of a team hour of 100 EUR. The initial estimated costs or the sales price per team hour are thus fulfilled for both sides. 

2. scenario: 5% less complexity, 10% less effort

The following services were rendered: 

  • 950 Story Points (5 % reduction)
  • 6,840 hours (10% reduction of hours per Story Point * number of Story Points delivered)

These were accounted for as follows:

  • 950 Story Points * 400 EUR = 380,000 EUR
  • 6,840 hours * 50 EUR = 342,000 EUR

This results in total costs of 722,000 EUR. The project costs decrease for the client . The average sale  price of a team hour is around 106 EUR. The sales price for a team hour increases for the contractor.

3rd scenario: 30% more complexity, 15% more effort

The following services were rendered: 

  • 1,300 story points (30% more complexity)
  • 15,600 hours (15% more effort per Story Point * number of Story Points delivered)

These were accounted for as follows:

  • 1,000 Story Points * 400 EUR = 400,000 EUR
  • 300 Story Points * 100 EUR = 100,000 EUR (reduced price for an  unpredictable complexity)
  • 15,600 hours * 50 EUR = 780,000 EUR

This results in total costs of 1,280,000 EUR. The total costs increase for the client. The average selling price of a team hour is around 82 EUR and thus decreases for the client.

Putting it simply, this results in the following consequences for contractor and client, depending on the respective scenario:

Risk sharing for contractor and client

The importance of checkpoints

An important component of the combined model is the checkpoint. At this checkpoint, you check whether the assumptions made are still correct. For example, the checkpoint can be set after six sprints. The questions like these are to be clarified here:

  • Is the assumed efficiency of the implementation correct? 
  • Does the complexity increase significantly in the course of detailing? 
  • Were we able to check the initial assumptions and mitigate technical risks?

Experience and trust are crucial

It is important that you know the effort per story point and the speed of the development team (Velocity). Therefore, at least an initial phase should start in this particular project setup, so that a realistic assessment of story points is possible. The combined model is thus a model based on experience. And on trust. 

If experience and trust are given, this model is well suited to distribute the risk equally between the two parties. The combined model creates two contracting parties that can communicate and work with each other on equal terms.


Do you have any questions?

You want to know more about pricing for software contracts?

Do you want to develop an environment in your company that enables working with agile methods?

Please contact Richard Brenner via eMail or on LinkedIn with your questions.