How much does this cost?

there are so many men who can figure costs, and so few who can measure value - unknown




“How much will this cost?”

“How long will it take?”

“What am I going to get?”

These are the questions that every agile project gets asked at some point. And while “as much as you're willing to spend,” “as long as necessary,” and “whatever you ask for” are perfectly acceptable, many customers are uncomfortable with these answers. This may reflect more on the customer than the team, but can lead to the misconception that the development team is writing themselves a blank cheque. How then does an agile team define and scope a project where the customer requires fixed time, cost, or scope?

This presentation will provide guidance and direction on how to quote for and budget agile projects, as well as how to change the questions in the first place.

Keywords: agile, estimation, contracts


Contracts, budgets, and quotes: These three concepts can send the most ardent agile practitioners running for cover.

They shouldn't.

Understanding outcomes, value, and trust is the key to successfully building an agile contract. Without them, an organisation is naturally constrained in their ability to adapt and leverage a changing market.


Fundamentally, a contract is defined by the level of risk each party is willing to accept. To manage this risk, there are three questions that every customer will ask a project at some point, agile or not.

  1. “How much will this cost?”
  2. “How long will it take?”
  3. “What am I going to get?”

And while “as much as you're willing to spend,” “as long as necessary,” and “whatever you ask for” are sometimes acceptable answers, many customers are uncomfortable with this approach. This reflects more on the customer than the team, but has often led to the misconception that agile teams are writing themselves a blank cheque.

Let's be clear about the basics first. There is a fundamental relationship between time, cost, and scope. To understand this, it can help to visualise your project as a pipeline, as shown in Exhibit 1. The width of the pipe is your team size, the length is the time available to deliver, and the flow is your scope. Any variations require one of these three variables to change. Effectively, and simplistically, you have three options: increase capacity (cost), increase duration (time), or drop requirement (scope).


Exhibit 1: The relationship between time, cost, and scope

Overtime isn't a solution, as current research suggests that long-term, sustained, overtime leads to a significant reduction in productivity (Seo, 2011) (Virtanen, Ferrie, Singh-Manoux, Shipley, Vahtera, Marmot & Kivimäki, 2010) (Proctor, White, Robins, Echeverria & Rocskay, 1996) (MacDonald & Bendak, 2000).

We also need to understand that every project has constraints and that these can be important. However, by definition, agile delivery practices put the customer in control of the product and do not constrain scope beyond setting project context at the start. The functionality of a product may evolve as the backlog changes between iterations. Even the agile manifesto states this very clearly: “customer collaboration over contract negotiation.” In other words, the scope of the project is unpredictable.

So what does this mean for contracts? Contracts rely on predictability: I'll pay you X to do Y, which demonstrates a fundamental flaw in how we traditionally build contracts. So for an agile contract, we need to find a different constraint—a different way of agreeing to a commitment.

Let's start where all contracts should start: trust.


In large part, the form and flexibility of a contract between parties depends on the level of trust that exists between them. This can be defined across four distinct levels (See Exhibit 2).


Exhibit 2: The trust pyramid.

  1. Reference: This is the lowest form of trust and exists where trust between the parties is based on the reference of a mutually trusted third party.
  2. Contract: This is the most common level of trust, and the majority of relationships do not extend beyond this. This exists where parties create legally binding contracts as the core mechanism to enable trust between them.
  3. Identification: This level of trust is created over time, where parties have the opportunity to work together and build trust based on personal experiences.
  4. Partnership: This is the highest level of trust between two parties and exists when both parties share the same goals and outcomes. This may take the form of a strategic partnership or similar structure.

Understanding the levels of trust is essential in developing agile contracts.


This brings us to the core of this paper—the contacts themselves. Experience shows that most software contacts come in three forms: time and materials, outcome-based, or fixed contracts.


Time and materials (also known as T&M) is the most “agile” contract model and provides the greatest flexibility to change, scale, and adapt on demand. If you are able to identify and prioritise the value of a user story, a T&M contract gives you the flexibility to stop work (or at least trigger the contract closure clauses) when the cost of delivery is greater than the value of what is delivered. In other words, work should continue until the customer chooses to stop.


Exhibit 3: Cost versus value.

To understand what this means, it can help to visualise the rate of spending. In Exhibit 3, we track the value of each story against a linear financial spend (fixed-team size). In this example, the initial stories are of low value, followed by low effort, yet high value, tasks, followed by the lower value and harder tasks. In this case, it is very easy to see where the T&M contract should come to an end as the value diminishes against the cost.

If additional controls are needed, you can create a capped T&M contract, which limits financial spend to a fixed amount. It's important to ensure that the cap is high enough that the overall return on investment is positive. You can also introduce a guaranteed minimum spend or delivery bonuses to encourage productivity in the team.


Gaining popularity in recent time is the use of outcome-based or performance-based contracts. These are sometimes known as “power by the hour” in reference to the support contracts for aircraft engines that are based on the hours flown rather than fixed or annualised contracts.

The difficulty is defining an outcome which is measurable and mutually acceptable from the financial perspective.

Common examples of outcome-based contracts are Software-as-a-Service and other pay per use models. Referring back to the levels of trust, for outcome-based contracts to be successful, organisations need to be near the top of the trust pyramid at the level of partnerships.

In developing an outcome-based contract you will need to set the following parameters:

  • The expected outcome: Fairly obviously you need to define the outcome that you are measuring.
  • The outcome measures and levels: How will you measure the performance of the outcome and how are these rated against the contract.
  • The payment curve: How will you pay (or be paid) against the performance measures and levels above. Also are there sufficient incentives to exceed the baseline measure.
  • The risks to the outcome: What risks are you willing to accept (especially relating to difficulties in measuring the outcome).


The fact is that many customers, especially those at the lower levels of the trust pyramid, or where there are significant capital costs, require “fixed” contracts. In the standard case, this is a combination of fixed cost, time, or scope. Providing fixed quotes can sometimes be compatible with agile, but requires careful attention to manage the flexible component in a way that is reasonable and achievable.


Where your customer asks for a fixed price quote, prior to work commencing, but is flexible on the scope of delivery, and how long it takes.

For example: Provide operational support and maintenance services.

How to quote: Identify, and estimate, the approximate user stories in iteration 0. Use this to calculate a first-order cost range.

How to deliver: Keep iterations short, as longer iterations have a tendency to cost overruns.

How to measure: Monitor velocity and burn-rate, as these are your key indicators of cost. Adjust scope and time as required.


Where your customer asks for final delivery by a specific date, but is flexible in scope and cost.

For example: Design and print new marketing material for a product launch.

How to estimate: Using historical velocity data, each team can forecast the number of stories they can deliver by the due date.

How to deliver: Strictly enforce timeboxes. The duration is defined by a fixed number of iterations, and extending an iteration will push out your final date.

How to measure: Tracking team and project velocity and/or cycle time.


Where your customer has a fixed set of requirements, but is flexible in the time it takes to deliver, and the cost of delivery.

For example: Change existing reports to accommodate internal reporting requirements.

How to plan: Focus on backlog definition and estimation before commencing work, to ensure accurate scope definition.

How to deliver: Work in predefined, and agreed, backlog order.

How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess possible delivery dates.


Where your customer asks for a fixed price quote, with final delivery due by a specified date. In this situation, the exact set of features, or scope, is flexible.

For example: Work on an agreed product until the end of the financial year.

How to quote and estimate: Calculate total cost as cost per week, or cost per iteration—this is one of the simplest types of quotations and fully compatible with agile because you are pricing the project based on what the customer expects and is willing to pay, and not on the potential estimated cost. The cost is effectively budgeted, instead of estimated.

How to deliver: In addition to the fixed time and cost criteria, regularly maintain the backlog.

How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess how many stories can be delivered in the available time. Measure the burn-rate to ensure that the costs are in line with the expected budget.


Where your customer asks for a fixed price quote, for a predefined set of requirements. In this case, the final date for delivery is flexible.

For example: Build and deliver a product to architectural specifications.

How to quote and plan: Increase the contingency (% or $) during iteration 0 to ensure your quote allows for unexpected delays that would affect your cost to deliver.

How to deliver: In addition to the fixed cost and scope criteria; adjust the final delivery date.

How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess the possible delivery date for all the accepted stories.

Measure the burn-rate to ensure that the costs are in line with the expected budget.


Where your customer asks for a fixed set of requirements, with final delivery due by a specified date. In this situation, the total cost to the customer is flexible.

For example: Fulfilling legal requirements prior to the legal cut-off date.

How to estimate and plan: During iteration 0, preassign requirements by week or iteration to define the scope delivery timetable. Pad the schedule with extra time, to cater for unexpected defects, or technical debt.

How to deliver: In addition to the criteria in fixed time and fixed scope; increase the team size to ensure the scope is completed on time.

How to measure: Measure how many stories have been accepted so far, and project the rate of acceptance into the future to assess the possible delivery date for all the accepted stories. Measure the burn-rate and keep the customer informed of the likely final cost of the project.


In this final scenario, your customer gives you no flexibility in the budget, schedule, or scope.

Cancel the work. This is not suitable for agile, and should be run using a traditional framework. Even then it is likely to fail without some flexibility.

But… if you start with a time and materials pilot, you are able to significantly mitigate the risk associated with a later fully fixed contract.


So far we've covered how to create an agile contract in the context of two separate organisations. It's also possible to use these approaches to structure a funding model if the work is being undertaken internally.

Be aware though, that because most finance divisions require business as usual (BAU) budgets and project budgets at least 18 months ahead, it can be difficult to react or proact to opportunities in the market in an agile context.

I'd like to leave you with one final approach for internally funded projects: change the question. When business cases are raised for new projects, don't base your budget on “How much will it cost,” but rather “How much is it worth.” By putting to benefits at the fore, and delivering an agile scope, projects can focus on what is most important—business value.


Fundamentally, all of these approaches come down to the core principle of managing risk. Your contract terms are going to be set by the level of risk each party is willing to accept. In an agile context, what you want to avoid is the situation where a contract overly constrains a partnership where the risk is already low or can be accepted.

Given what we know now, let's go back and answer the original three questions.

Q: “How much is this going to cost?”

A: “As much as you're willing to spend.”

Q: “How long is this going to take?”

A: “As long as it takes to deliver what you ask.”

Q: “What am I going to get?”

A: “Whatever you tell us you want.”



Evan Leybourn pioneered the field of agile business management, applying the successful concepts and practices from the Lean and agile movements to corporate management. He keeps busy as an executive consultant for IBM, start-up mentor, non-executive director, conference speaker, and author of Directing the Agile Organisation and #noprojects.

The views expressed are drawn from my extensive experience in the industry, and do not in any way reflect the views of my organisation.


img Evan Leybourn | img @eleybourn | img Evan Leybourn


MacDonald, W., & S. Bendak. (2000). Effects of workload and 8- versus 12-h workday duration on test battery performance. International Journal of Industrial Ergonomics, 26(3), 399–416.

Proctor, S. P., White, R. F., Robins, T. G., Echeverria, D. & Rocskay, A. Z. (1996). Effect of overtime work on cognitive function in automotive workers. Scandinavian Journal of Work, Environment and Health, 22, 124–132.

Seo, Ji-Won. (2011). Better work discussion paper series no. 2. International Labour Organisation.

Virtanen, Marianna, et al. (2010). Overtime work and incident coronary heart disease: The Whitehall II prospective cohort study. European Heart Journal.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMl or any listed author.

© 2016, Evan Leybourn
Originally published as part of the 2016 PMI® Global Congress Proceedings – Barcelona, Spain



Related Content


Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.