We are a small company working in web development. I like Agile and I tend to use it within my team. The issue is: usually, clients need to get quoted with a lump sum of their project that will not adapt to their usual needs for changes. If I started charging them by change time, eventually they will think that we are over-charging them and these new requirements or changes aren't worthy to be charged.

How do you deal with your customers regarding charging and agile?

  • Use Kanban for external clients. Agile methodologies such as scrum only works well in an environment where the whole organisation has adopted it and are happy to set deadlines based on the velocity of the team.
    – bobo2000
    Commented Mar 15, 2017 at 11:25
  • Is the irst question important? Do you need to convince clients that you use agile? Do they challenge that assertion? Surely the only real question is "How do I charge for agile?"
    – MCW
    Commented Mar 15, 2017 at 20:21

6 Answers 6


This question has two levels:

  1. actual problem of contracting the work for agile team
  2. does it really matter how the work is contracted?

It actually doesn't matter how the contract looks

Even if you sign fixed scope/price contract with customer you still might be better off using agile/iterative approach. Use it as risk minimizing factor.

Nothing stops you from using e.g Scrum for fixed scope bid:

  • You can work in iterations

  • You can deliver increments of working software every Sprint

  • You can incorporate clients feedback (it might cause change/request, formal scope adjustment)

    But what is more important, in the situation you run behind and you have problems with delivering 100% of scope on time/budget (which happens in most of software projects anyway)... you will be better off with agile approach.

You have better negotiation position with your customer:

  • Most importantly, you will have big part of the scope done and potentially shippable

  • Customer has probably seen your progress, so there is much more confidence and trust if your ability to eventually deliver, therefore it will be easier to find common ground

Best contract for agile team

Most commonly used contract is Time & Material where customer pays for your team's work.

I've seen interested variation of agile contract that was proposed by Ken Schwaber in one of his books (I think Agile Project Management with Scrum):

  • After initial Release Planning you agree on the scope and contract value

  • If all the work is done and under budget you get 10% bonus added (not sure about exact figure)

  • Customer can decide to stop the work after each Sprint and pay you 20% of remaining budget as a re-compensate for the fact that you need to instantly reassign team to other teams

  • If you go over budget then customer is paying you much lower rate for the rest of work (you're sharing the risk of going over).

How it all ties together

I usually approached your situation initially without even proposing anything else than fixed price contract as it seemed to be lost battle without relationship and trust. To build this relationship? Proving that you're professional and you know what you're doing is the best way :)

Upon contract signing I would inform customer that you'll be using Scrum for this project and invite them to participate. This is crucial, you want them to see for themselves how "their" software is built, you want then to have influence and see they can realize business value faster. If client stakeholders have real need for the software and you will engage them, there is good chance they will get addicted to the approach.

After first project, you can try agile contract described above or move strictly to time & material. It's matter of preference and business circumstances on both client and your company.

  • Really well written and thought through. I'm in the process of introducing Agile into the agency I just started working at, and this has been the biggest question I've had for a while. Love Ken Schwaber's approach too.
    – dKen
    Commented Mar 14, 2017 at 11:04
  • @dKen thx! good luck, as stated in my answer start with using it to minimize risk and then everything else will get easier - including contract negotiation. Commented Mar 14, 2017 at 12:25

Discuss it with them and get their buy-in first.

Agile won't work very well if not everyone involved is on-board. Worst-case, you can still try to use Agile internally while working with external customers in a more Waterfall style.

Do not try to just foist Agile on them. Inform them about the benefits and let them see why it would be a good idea. If they're not buying it, do not just go ahead and start charging them for something that wasn't agreed upon.

  • +1 - they're not selling the benefits to the client. that's a mistake
    – JeffO
    Commented Mar 14, 2017 at 21:07
  • +1 for external clients I do waterfall or kanban, scrum is velocity based which does not work well when you have pre-defined deadlines since the deadlines are not based on the velocity of the team.
    – bobo2000
    Commented Mar 15, 2017 at 11:23

TL:DR: Always use agile, change your reporting, not your contracts.

It sounds like the root problem here isn't about using agile nor the kind of contract you use, it's about managing Change Management.

Regardless of if you use agile or traditional development techniques any project over roughly a week is going to see changes. You need to help your client understand the costs of change and how this impacts the contract.

Using agile development means you have metrics that are usually more accurate and reflective of changes. Even if you use classic velocity based burn downs with best case, worst case (a good example can be found in Henrik Kniberg's Product Owner YouTube video) you can show a client, "Okay if you add this scope, we will either ship on X date, or need to drop Y scope to make your date."

To take it to a more advanced and highly data-driven model, I recommend Troy Magennis' forecasting model. You can find this at FocusedObjective.com where he offers the models free. These spreadsheets can model single and multi-feature projects and allow you to give highly accurate, Monte Carlo simulation based, forecasts for your projects. You'll be able to easily sit with a client and go "if we do this, X happens, this and Y happens and this Z happens. What do you want to do?".



eventually they will think that we are over-charging them and these new requirements or changes aren't worthy to be charged.

The client should decide on the order of the backlog. If they feel enough value has been achieved then they should be able to cancel the development team at anytime. So if they think it is not worthy anymore you are done, time for the next client.

Recently I wrote about Agile and contracts on Medium, my final pitch was:

Don’t pay for features you do not need, minimize risk by working in short iterations and start monetising after the first most valuable features have been delivered as working software. Why settle for less?

I suggested you use a fixed budget and the client decides what has priority, just don't specify requirements in the contract. Jeff Sutherland wrote an example about a contract win-win for developers and clients in his latest book. (will try to summarize later, time for a meeting now ;-)

  • Many clients are not value based - so your first point won't work well. They just want y amount of work to be done in x time without taking into account complexity of the tasks relative to each other.
    – bobo2000
    Commented Mar 15, 2017 at 11:27
  • That's the whole idea behind Agile. Time and budget is fixed and scope is variable. If your clients want a fixed scope then don't do Agile, although delivering in small iterations still holds some value. You can never fix Scope, Quality, Time and Budget. It is just not possible, you will be lying to your customers. Either the client or you have to take the loss of the extra costs as scope increases or time runs out if you have a fixed price. Creating software is a creative process with high uncertainty, it is not a repeatable process where you can calculate the outcome upfront. Commented Mar 15, 2017 at 11:38
  • @bobo2000 btw, my article starts with that problem. As most clients expect to be certain what they get for their money upfront. Which seems very logical. The business2business world is probably not yet ready for Agile product development. Commented Mar 15, 2017 at 11:42
  • 1
    I am a strong advocate in agile 'Time and budget is fixed and scope is variable.', but try telling that to an external client who doesn't understand the software development process and wants everything to be delivered...often what happens, the work does get delivered after a lot of overtime. Agile only works if the whole organisation adopts it, right down to the sales team. Velocity during the initial planning phases is also very hard to work out on new projects, unless that type of work has been done before so it is hard to set a timeframe immediately which external clients expect.
    – bobo2000
    Commented Mar 15, 2017 at 11:45

For agile to work the clients, product owners, scrum masters and team have to be trained (or should buy the concept) on agile.

I have seen many projects failing scrum sprints as the client's priority and sprint priorities clash and scope of sprints changes.

Agile is not remedy for every project. Evaluate your situation and make Waterfall with fixed priced model work better for you. You can use wireframes, workflow diagrams or sequence diagrams to get the requirements clarified better so as to reduce change requests.



You have two problems:

1) How to handle change requests

Minor tweaks are fine, but at some point you will need to be firm, charge the clients for them and make them aware how the changes will impact the delivery date.

I suggest keeping a change log to track all change requests, and try and ensure that the requirement gathering is done thoroughly before work has begun.

2) Use Kanban, not Scrum for external clients.

Scrum is value and velocity based. The idea behind Scrum is where you only deliver x amount of work based on y velocity. So you prioritise the backlog according to what gives the most value and then omit the rest when you have run out of time.

Many clients do not care about this, and it only works extremely well when you're working in an environment or project that adopts this approach.

Since Kanban is based on cycle time and not velocity it is perfect for delivering work where there are fixed deadlines. It is also agile, since any new requirement goes to the bottom of the backlog where delivery is done in a conveyer belt style way.

  • 1
    There is nothing in Scrum guide regarding velocity, it's one of the techniques that can be used, but is not mandatory. You're describing some edge case where in specific Sprint you have capacity of e.g. 10 points and 4 backlogs items worth 3,3,3 and 2. In this case you're saying that team will commit to 9 points (based on the capacity/velocity) and 2 points will be wasted. In Kanban because there aren't fixed Sprints you're saying they will just continue working? In some instances this might be the case, but many Kanban teams also have regular cadence of inspection and adaptation! Commented Mar 15, 2017 at 15:56
  • Burndown charts track velocity of the team, and from experience is the most useful metric when doing Scrum for forecasting deliverables.
    – bobo2000
    Commented Mar 15, 2017 at 16:21
  • 1
    Which again is optional and outside of scope of core Scrum. I don't understand how this is relevant in context in recommending Kanban over Scrum. Even in your scenario of "running out of time", slack time at the end of the Sprint, in Kanban WIP limit should introduce slack time in similar way. Commented Mar 15, 2017 at 16:29
  • Never used WIP limit admittedly, cycle time is the only metric I measure using kanban.
    – bobo2000
    Commented Mar 15, 2017 at 17:19
  • 1
    Sorry, I don't follow. Work in Progress Limit is one of five Core Principles of Kanban: djaa.com/principles-kanban-method-0 Commented Mar 15, 2017 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.