Customer asks for a contract with the price for the whole project, but we are Agile

Question

We have a client to whom we have explained the whole Agile process, where he pays for each sprint (as billing cycles), and he agreed to it.

We are a new company and we don't really have a legal advisor. That being said, we are charging 50% of the billing cycle at the start, and 50% at the end; and the customer made the first payment before signing the contract. (The project has about 4 billing cycles so far).

Today we sent the contract for the first cycle, but the customer asked us to send a contract for the whole project. Since we are doing Agile development, we charge per cycle, meaning that each cycle's price might change depending on requirements, therefore there is no such thing as a "total price", but only estimations.

How do we [re]explain this to the customer?

PS: Yes, clearly we were not clear enough when explaining this the first time, so we want to re-explain it without sounding like we never told this about.

Considering the fact that he knows he payed just for the first cycle, how do we explain that others cycles are just an estimate? (The document describing each cycle had a disclosure that says: "Changes in requirement might cause price changes")

Answer 1

Bill them the same amount for each cycle

Since we are doing Agile development... each cycle's price might change depending on requirements

It should not. You want to keep a dedicated team of cross-functional resources who are working on this client's project. It is neither productive for you nor cost effective for the client to bring in new people for one sprint, spend time on gaining the domain knowledge and go away for the next.

This will also keep the billing simple and predictable for the customer.

You should do your high-level planning on what this dedicated team can accomplish in each sprint. In backlog refinement and sprint planning you should explain the trade offs to the customer if many bells and whistles get added on.

Answer 2

In case you already defined the Minimum Viable Product with your client, you could define prices based rather on market prices for the desired user stories (not hour estimations). Then your customer would pay for some stories more than he would than if it was based on an "hour price" and for some less. By doing so you have coupled your interests as a vendor the interests of your customer which should be do goal: The most important and valuable get implemented first. This is some interesting approach I read originally in the book "Wie schätzt man in agilen Projekten: - oder wieso Scrum-Projekte [...] By Boris Gloger"

Your customer should consider that he has a lot more flexibility than in traditional projects in regards of "change for free". He can just replace backlog items with others that become more important on the fly, if the other items have the same "size". I read estimations that are talking about 6 sprints before you have something real to show. You can probably consider building a bit larger clusters with a fixed price than just one sprint. I think if you offer full transparency to your customer he can act more like an investor/stakeholder here than a "traditional customer". This would require a lot of trust into the product owner on your side. Maybe you can have a smooth transition into the Scrum process meaning that you are taking a bit more risk on your side until the customer has built the trust it needs.

Answer 3

You are party to the agreement. You can simply say no, that supplying a firm price on uncertain requirements and specs is simply not in your best interest. Or, and this is a huge or, you have to load it with a ton of contingency that would likely quadruple his price or worse, in order for you to assume the risk of uncertain requirements and specs...which is not in his best interest.

But keep in my your customer's perspective. Since they are not constantly competing each sprint, they would perceive losing leverage in obtaining a fair and competitive price. They're already in bed with you and invested in you. This means you can start inflating your price on a whim and they have little leverage to hold it down except to fire you completely, which may be more expensive for them and therefore, not really a viable option. This is about trust, which your customer may have just indicated a lack of....

Answer 4

If you have a consistent scrum team and sprint lengths (both of which you should if you're operating in the Scrum model), you should have a consistent sprint cost. If you have other skills that are needed sometimes (like a DBA or UI designer) you will need to work that into the cost somehow, but I'd advise incorporating those skills into the team in the long term.

If you have a small project, you might have a good idea of the scope of the whole thing, but a lot of times you may be looking at a product increment or release that's a few months out that you've created the backlog for and the team has at least reviewed the stories. From that, you can do a burn-up chart to see around how many sprints it may take to get through that scope. It sounds like you may have already done this.

Let's say the burn-up chart shows that you'll meet the expected scope in 6 - 8 sprints. You could now bill for 8 sprints as long as the customer understands that during your sprint reviews with them, there may be changes in the backlog to match the understanding of the project gained as it progresses.

It's important to also make sure your customer understands that their big protection is that you create potentially shippable product every sprint, so at any time, they can decide enough scope is done to meet their needs and they can call it a wrap. That way even if the backlog changes, and some stories get pushed out in favor of newly discovered important stories, they can still be done at the 8 sprint mark and they'll have working software.

Answer 5

A contract and a bill do not need to be the same thing.

I have seen Agile contracts that are pretty much a brief summation of how the scrum team will iteratively deliver work and how the client will iteratively provide input. These contracts do no list a fixed price or expiration date, they are at will and focus on the client contracting the supplier as long as the service provided is valuable.

The amount to be paid during each payment schedule is negotiable but like Daniel points out, a fixed Scrum team with fixed iteration length should have a fairly predictable operational cost. Other easily predicted costs include things like hardware/infrastructure and licenses. Exceptions can be handled in the contract via a time & materials type of agreement. You may want to put a % limiter on allowable T&M costs if the client is uncomfortable with the prospect of being in any type of T&M agreement. The important thing in the Agile contract is that you are up front about how and when bills are calculated. The initial contract doesn't need to specify the total billable amount.

Now...a lot of clients have a fixed budget and want to understand how long they can burn budget. For this, a scrum team with a fixed iteration/velocity can provide the client with roughly how long they can burn. The important connection to establish with the client, however, is that "On X budget, we estimate to be able to deliver valuable features for Y-Z days, weeks, months, etc. More importantly, help us understand what features are most important now, and throughout our engagement, so that we always can deliver optimal value."