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.

How Do I Find the Right Agile Software Development Company for My Project?

Price is often the crucial point when it comes to selecting an agile software development partner. Different offers can be easily compared and thus you can make what seems to be a safe choice. At least at first glance. 

But if you do not take the provider’s ability into account or underestimate it, the initial savings can quickly be reversed. For example, the provider may not meet the project’s requirements, and the project team may suffer. If you scrape expenses at the wrong end, the additional cost and time will be significantly higher than the savings at the beginning. 

We will show you which quality criteria are important for an agile approach and how you can select the right agile software development vendor for your agile project with the help of a structured process.

Criteria for selection of an agile software development company 

It is crucial to deal with the topic of quality criteria before starting the selection process. Only this way, you will know what to look for during the selection interviews. In our opinion, you should definitely consider the following criteria:

  • Experience in Agility: The more experience an agile software development company has with agile methods, the better. Agile project development can only be successful if an “Agile Culture” is lived.
  • Well-established Team: An established team is preferable over a newly assembled one. Because well-established teams can often be much more productive than a new team. For longer projects, you should also take turnover in the team into account. We are familiar with this issue, especially in offshore teams, where individual developers can be replaced at any time.
  • Direct Communication: This factor is particularly important for agile projects. It must be ensured that your experts can work with the provider’s experts directly –  ideally in the same scrum team. From our own experience, problems often arise when there are too many handovers between individual team members. Decisions have to be made quickly, without long decision-making processes. 
  • Experience in the Domain: The experience in the domain also plays an important role, especially at the team members’ level. International references are often mentioned, but the corresponding team does not have this experience. 
  • Culture Fit: It is important to understand the mindset and development processes of the provider. You should check in advance to what extent this fits with your own company culture and enables a close cooperation.
  • Degree of Dependency:  It makes sense to consider how to keep the extent of dependence on your provider low in further course of the project.One possibility is to rely on open standards. It makes it easier to change the supplier at a later point or to train its own developers. 
  • System Architecture: The architecture of a new solution must fit into the existing system landscape. A completely new system with new technologies increases complexity and makes maintenance more difficult later on if the skills available are not sufficient within the organization. This also increases the dependency on the agile software vendor.
  • Maintenance: Once the software has been developed, the maintenance phase begins. It is well known that it takes much longer than the development phase. Therefore, you should review the agile software suppliers strategies for this phase and test how quickly they react to unforeseen errors such as production incidents.

In addition to the quality criteria, as a customer, you should know your most important NFRs (Non-functional Requirements), such as security, scalability, testability. This is the only way you can examine the selection process and whether providers can fulfill these and communicate them directly. Otherwise, the system may implement security requirements at significantly higher costs or, in the worst case, not at all. It is well known that NFRs influence the system architecture more than functional requirements. In the worst case, a product may not be able to implement these NFRs at all.

Find the right agile software development company with this 4 step process

These preliminary considerations provide the basis for a structured process that allows you to select providers based on the most important criteria in four steps. 

1. Make a preliminary selection

When you start a tender for an agile project, you will receive a number of offers. The first step is to preselect the offers. 

The purchasing department usually takes over the pre-selection. Bidders are chosen based on the price and the qualification criteria described above. 

 2. Conduct intensive discussions

After the pre-selection has been implemented, intensive discussions between your and the provider’s experts take place. These discussions occur to validate the first impression. 

Also, requirements as NFRs can be addressed at this stage to give the provider a detailed idea of what is expected from him during project implementation.

 3. Conduct the prototype phase

The prototype phase is crucial, but it is often not done. Especially if you have not worked with the provider yet, you should not skip this phase under any circumstances. 

Ideally, the prototype phase should be done with several selected providers. The goal of this phase is to assess the collaboration based on the executable software. This will give you a better understanding of whether cooperation with the software development company works and whether all quality criteria can be met. 

Important: During the prototype phase, you should make sure that it is executed with the final team. The employees who will later be responsible for the product development should already work on the prototype in the final constellation during this phase.

4. Start product development

The software created during the prototype stage and the feedback from the experts regarding the cooperation with the provider serves as the basis for decisions that will further cut back the selection making. At the end of this phase, you should select a company with whom you will carry out product development.

However, before entering the development phase, contract negotiations must be conducted. With agile projects, you should be aware of several pitfalls when drafting the contract. We have summarized essential tips for you to create a solid contractual basis for your agile projects.

Price is not the decisive criterion

Price is usually not the best selection criterion, even if it seems so at first glance. It is important to be aware of the most important quality criteria in advance and validate them in a structured process for potential providers.

The following list of questions will help you to assess the quality of the provider:

  • How much experience with agile methods does the company have?
  • Is it guaranteed that I get a well-established experienced team? Do I have a direct influence on the people who work in my team?
  • Is a direct communication of customer’s and provider’s team members ensured?
  • Does the provider and, especially, the team implementing my project, have experience in my domain?
  • For longer running initiatives: How high is the fluctuation of people in the team?
  • Do you know your non-functional requirements?
  • How directly can you communicate with the implementation team?
  • Is the implementation team perhaps a part of your own team?
  • How good is the agile provider in the maintenance phase?

Do you have further questions about the selection of agile providers?

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

Please contact me via eMail or on LinkedIn with your questions.

Classic or agile contracts: How to find the right contract type

Traditional projects and their contracts have a decisive weakness. Even though they offer a large measure of (a supposed) budget security, they can hardly keep up with the speed of the fast-moving business world.

Thus, instead of the sureness of knowing when a product is ready and what functions it has, you have the danger of receiving an outdated product that no longer meets the up-to-date requirements.

Especially with complex software problems, the classic contracts’ limits are reached quickly. This is because modern software development is becoming increasingly agile. This means: neither the product that is to be delivered nor when the product will be done is clearly defined at the beginning of the joint work. Contractually, these patterns can only be covered by contracts that make agile collaboration possible. 

In this article, you will learn what exactly makes contracts ‘agile’ and whether they are also suitable for your project.

Four crucial differences between classic and agile contracts

First of all, let’s look at the difference between classic and agile contracts. I have summarized the most important of them in a short video:

It can be stated that the two types of contracts differ in four basic points in particular:

  1. Project scope: In a classic contract for work, the project scope is usually fixed for a long period of time. This means that all requirements are collected in a specification document and processed afterward. This is not the case with an agile contract. The changes here can be made after each sprint. This allows the development team to take feedback into account promptly. However, with agile contracts, the basis is a backlog, with the effort being estimated at the beginning.
  2. Project period: In classic contracts, the time of the releases and the milestones is fixed. With agile contracts, the following applies: the project is finished as soon as the product is ready. Of course, you can also define a time period or a fixed number of sprints. You can then go into production with whatever is ready by that time.
  3. Release cycles: The release cycles for classic projects can last from several months to years.  When it comes to agile contracts, there is ideally a prototype after each cycle (sprint), which can be tested.
  4. Budget: With both contract models, the budget can be deducted according to T&M (Time & Materials), or it can be fixed. In the case of agile, this means that a certain “Run-Rate” of the team has to be budgeted.
  5. Control: Output vs. outcome applies here. For example, in the case of classic contracts, it is measured whether the development team has reached the corresponding milestone at time X. With agile contracts, it is checked whether the product meets the customer’s requirements.

In summary, it can be said that in classic contracts, budget security is clearly in focus. Agile contracts give the development team much more freedom to react to the short-term changes and to gather feedback regularly in order to ultimately develop the best product for customers.

How to find the right contract type

The choice between an agile or classic contract depends on two basic factors: the complexity of the project and the way your company works.

Complex projects need agile contracts

An agile contract is not the best choice for every project. It is crucial to think about the tasks that arise in the project and how well you can define them in advance. The following questions can help you with this:

  • Are you sure that the general situation will not change during the project?
  • Are you sure that the value of your company can be achieved exactly the way you have defined it?
  • Do the tasks consist exclusively of recurring activities?
  • Are the risks of the technical implementation low, and can the requirements be clearly formulated?
  • Is the project rather small and short-term, so that you don’t need a team for the support and further development of the product?
  • Are you buying a standardized product that does not require integration into an existing product?

If you can give a positive answer to all these questions, then a classic contract is probably enough. Your project and requirements can be precisely defined in advance. The situation is different if you can only answer “yes” to some of the questions. In this case, it is worth taking a closer look at the agile contracts.

No agile contracts without agile working methods

The complexity of your project is not the only decisive factor. If you are not able to implement agile projects in your company, an agile contract will not get you anywhere either.

In order to develop the best possible product in an agile way, there should be a vendor-customer relationship that allows close collaboration and some adaptability. The basis for this are the principles of the agile manifesto. The manifesto originally comes from software development. Nevertheless, it can also be applied to companies. 

Consider whether you have a basis for agile projects in your company and can guarantee the following points:

  • Feedback Cycles: You are able to implement fast feedback cycles (ideally every 2 to 4 weeks) and provide continuous feedback to the development team.
  • Transparency: You can ensure complete transparency during the project. This means that the development team has access to the backlog, to the progress of the implementation of different features and to the results of each feedback cycle.
  • Variable project scope: You agree that the feedback after each cycle is incorporated into further product development. Project scope and tasks can be adjusted accordingly to it. The option must also be specified contractually, for example, via a “Changes for free” clause. It allows changes to be made in the backlog as long as they do not involve any additional work.
  • Effective collaboration: You can ensure close cooperation between yourself, the development team, and the end customer. Ideally, the team works in one place to make direct and informal communication possible. It is an advantage if the vendor provides an on-site person who takes an active role in the project (not a management role that only serves as a link to the development team).

If you can implement the following points and also have complex projects, an agile contract is probably the right choice. If you have not established an agile mindset in your company yet but still want to work with agile projects, you can gradually approach this goal with the help of workshops. Feel free to contact us if you need further information. 

When is an agile approach useful?

No two projects are the same. And no two companies are alike. That’s why the same rigid framework conditions cannot always fully apply to the cooperation with your customers and partners.

Consider in advance what framework conditions you need for the respective project and whether your company lives an agile way of working. If you want to implement complex projects, an agile way of working or agile contracts offer a particularly solid basis.

Do you have further questions about the implementation of projects with agile contracts?

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

Please contact me via eMail or on LinkedIn with your questions.

Agile Teams: A Method to Enable Autonomy by Clarity of Roles

How can you enable teams to take initiative and autonomy by knowing their decision boundaries? In this blog post, I am sharing the concept for a workshop format that you can adapt to achieve that goal.

I used this method to address the following situation: within a classical organization, new cross-functional teams are put together and are now supposed to work in an agile way, but they are stuck at the beginning because they do not know what they are allowed to decide. In addition, the concept of shared responsibility in these new teams is new. A second effect is also that those teams are not stuck, but they are now willing to take initiative, decide certain things (like for example an architecture decision), but then their manager is not happy with the decision and overrules. Also leading to a stuck team.

The problem is that there are unspoken assumptions about what autonomy means between managers and the teams or other stakeholders around the team. We want to reveal those assumptions!

This blog post is based on the talks at the agile tour 2019 and at the ASQF agile night.

Important preconditions in the mindset

A basic precondition is that the organization and all the stakeholders understand the concept of small autonomous teams or the “law of the small team” as Denning describes it (Denning, 2018). Those teams act aligned with the product and corporate vision and are be able to self-direct and self-manage to achieve the goals.

Leaders and managers understand that they should enable those teams by following the concept: “Push authority to information”, one of the major principles of intent-based leadership because we know that they are the experts in their domain and can make the best decisions.

Source: Intent-Based Leadership Keynote by Jenni Jepsen @Agile Tour Vienna“

In order to that, we need to give control to the teams, which is a gradual shift, not a one-off “now you do it all” because we need to check if the competence in the team is there.

Source: Intent-Based Leadership Keynote by Jenni Jepsen @Agile Tour Vienna“

Third, it is clear that we can only manage the environment and not the people.

Workshop Format

The goal of the workshop format is to reveal who is ultimately deciding and how much of these decisions can be delegated to the team. This question can arise between for example the former line manager, the department lead, a software architect or other stakeholders.

Step 1: Key Decision Areas

First of all, we need to collect the most important decision areas where we faced problems or need clarity. It is important that you do not list all decision areas as this would end up in a huge probably Excel sheet that nobody uses later anymore.

Key decision areas can be for example:

  • Who is responsible for deciding on vacations?
  • Who can decide it is a good thing to go on home office or not?
  • Who decides ultimately about an architectural proposal?
  • Who decides how much a solution proposal can cost?
  •  Can we invest as a team in experimenting with solutions for a given problem?
  •  Can we decide on hiring external consultants?
  • Who is responsible for staffing the team?

Step 2: The RACI matrix

You can skip this step if you only need to clarify the delegation between one role and the team. If you have multiple stakeholders, the RACI matrix can help.

In the columns you list who is Responsible (R), who is Accountable (A), who needs to be consulted (C) before taking the decision and who needs to be informed (I) of the decision.

In the rows, you list the key decision areas. It is important that you do not go further in certain team roles. The team is either doing it as a team, but you do not delegate certain decisions to a certain team member.

deciding on vacations Individual Team Member Line Manager Team Team
homeoffice Team? Line Manager Team Line Manager
hiring external consultants Team Department Lead Team Lead Department Lead

Also, you should try to move the accountability as far as possible also to the team, not just being responsible.

Now, you create clarity who is accountable and who should do it (in most cases hopefully the team). Between those two now you can go further and clarify how far the delegation should go with delegation poker.

Thanks to Jenni Jepsen, who held an inspiring keynote at Agile Tour Vienna 2019 that motivated me to write this blog post.

Check out the upcoming training Intent-Based Leadership with Jenni Jepsen.

Step 3: Delegation Poker

Delegation is not a zero or one exercise. It is important to clarify how far a delegation should go. For example, if we hire external consultants, the department lead can expect that the team comes with a potential solution, but he keeps the budget authority and needs to sign it off. That would be delegation-level 3.

In order to clarify this, every team member and the involved manager or role who is accountable for a decision are to be discussed gets a deck of cards. Now everyone decides, how far they would expect that the accountable person delegates that decision to the team.

Like with planning poker this usually leads to good discussions and clarifications.

Step 4: Instepct & Adapt

I would suggest that you create an information radiator and use a delegation board on the wall where you see all the time what your delegation rules are. If you need to change it, do it and if you need to add further key decision areas do it on-the-job, for example during team retrospectives.

Hints and Tips

I would not necessarily start with that exercise before you set up the teams, but explain to the teams that we start to collect key decision areas on-the-job when we see that there is a problem. This avoids endless discussions before there is actually a problem.

If you face the situation that there is no real wish to put autonomy to the team, stop the exercise and work on the reasons why before.

The reason why I introduced the RACI matrix next to delegation poker is that delegation poker only allows for two roles, like manager and team playing it but the RACI matrix can show multiple stakeholders at once.

The goal is not to draw the lines but to reveal hidden assumptions and misconceptions.

Thanks to Jenni Jepsen, who held an inspiring keynote at Agile Tour Vienna 2019 that motivated me to write this blog post.

Check out the upcoming training Intent-Based Leadership with Jenni Jepsen.


Appelo, J. (2016). Managing for Happiness: Games, Tools, and Practices to Motivate Any Team. John Wiley & Sons, Inc.

Denning, S. (2018). The Age of Agile : How Smart Companies Are Transforming the Way Work Gets Done. Retrieved from