10

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")

  • 1
    Despite the fact there are five answers, I don't find this question clear enough to answer due to confusion over terms. The Contract is your agreement with the client, specifying what you are going to do, how much they pay, when you bill them plus a bunch of other things such as responsibilities of each party, termination clauses etc. There should be one contract. You don't mean "Billing Cycle", you mean 'Invoice' (or Bill) as far as I can see, and there should be as many of these as agreed in the contract. Then you have Agile cycles, which is nothing to do either the contract or the bills. – Marv Mills Aug 12 '15 at 10:37
  • 3
    You want to engage the client on a Time and Materials basis, billing at the end of each Agile Cycle, and your client wants to engage on a Fixed Price basis (by the sound of it) for the total project. You may be heading for a disaster unless you resolve this difference quickly and by an agreed contract. – Marv Mills Aug 12 '15 at 10:45
6

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.

  • I think this assumes that each sprint is about the same amount of working days. I think that is not how it is in reality since you probably have a fixed sprint length, but not a fixed amount of developer hours (or even developers). This is not the original definition of scrum but probably closer to some projects in the wild. What do you think about this? – Matthias Jost Aug 11 '15 at 20:20
  • You want to get paid on what business results you helped the client accomplish. Not cost plus. If there are any variations in your cost from sprint to sprint you should even it out. Also, the client's finance people would prefer a predictable bill. – Ashok Ramachandran Aug 11 '15 at 20:25
  • But that would mean you act less transparent to be more predictable. I guess that should be up to the customer or the project situation to decide. But I understand your point here. – Matthias Jost Aug 11 '15 at 20:29
2

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....

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.

2

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.

2

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."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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