Agile software development: How do you react *financially* to changing user requirements?

Question

There's one thing I've always wondered when reading about all this "agile development" stuff here on SE and other sites:

In "traditional" software engineering, you

1. collect the user's requirements,
2. write a specification based on these requirements,
3. give it to the customer and bill him for the work done so far,
4. do a (rough) technical design, so that you can estimate the cost of implementation,
5. give the user a price quote for the implementation,
6. wait for the customer to sign the specification and accept the offer,
7. design, implement, test,
8. bill.

If, during the process, the requirements change, you send an offer (with a price) for the desired changes (or do it for free if the change is small, you like the customer and the customer doesn't do it too often).

So, how does this work (financially) in an agile project, where frequent requirement changes are a part of the process?

• Do you write an offer for every design change? (Wouldn't this be quite a mess?)
• Or do you negotiate a fixed price and hope that the customer does not change the requirements too often? (Could be risky, I know customers who would use this opportunity to request new features for years before accepting that the project is completed.)
• Or do you just bill the customer for the total time required? (Could be risky for the customer, who does not know the cost in advance.)

Answer 1

In an ideal Agile world, you agree a price up front and a number of hours, but not scope. The customer decides what the minimum useful product is, rather than the product they really want, and that should estimate well short of the number of hours agreed.

Then you deliver to them iteratively and they change their minds all they want, but you never go over the number of hours agreed. In theory, and often in practice, they end up with the product they really need rather than the product they really want.

And if they want to continue to pay you for extra hours after the original agreed value, that's fine too. If you do a good enough job of making progress visible, through story cards, Greenhopper or whatever, you can make it very obvious to the customer which features they are losing (or at least deprioritising) each time they add something new, which largely puts a stop to frivolous changes.

There are two risks worthy of note here. First is that the customer may be scared off, if he hasn't understood Agility up-front. It does seem like he's taking all the risk. Only experience shows that he isn't really.

The second is that they must be engaged, throughout the whole process, or everyone will lose. Many customers fail to understand how engaged they must be until it's too late.

But if you, as a company, explain it well enough, everyone's a winner.

Answer 2

Some people attempted to give solutions to use Agility in fixed price projects in the past. I personally think it's generally not possible.

Scrum in particular is suited for product software companies, and is less used in service companies.

You can use some agility in your projects, such as iterations, daily stand-ups, burndorn, etc, but I can assure you that if you offer a certain amount of things for a certain price and deliver less than what was in the contract, you'll have a problem.

Please don't serve Agility à toutes les sauces. We must use the appropriate solution to a given problem.

Answer 3

This is not really related to Agile programming or whatever model you use. Working as a freelancer, I use a mix of Waterfall and V-model, but still have the same problem: what if the customer wants to change something during detailed design? What if he make changes during implementation?

The approach you have to use depends on the customer and your relations.

If a contact is a must-have for everything you do for this customer, because you know that he tries not to pay when he can, or he will try to sue you whenever possible, then yes, you have to write an offer for every tiny change in the requirements. It's not a mess: if you're well organized, it may not be too difficult to accommodate a new requirement during the development. But for sure, it's a loss of time and money, and it's rather strange to have to sign an offer for a change which will take you two hours to implement.

For other customers, the approach which work well is the following:

• When signing the first offer, specify the estimated cost and the maximum cost. Estimated cost doesn't mean anything legally: it's just an estimate. The maximum cost has legal value: if you say that the product will cost $3,000 to your customer, and it finally costs you $3,157.24, the customer will still have to pay $3,000. In practice, in most cases, the real cost will be less than the given maximum, and closer to your estimate.

• When the customer asks to change a requirement, estimate the cost it has and compare it to the actual cost and state. If you nearly finished the product and the real cost is $2,108.36 and the cost of the change is estimated to $150, just do it. If, on the other hand, there is the risk of reaching the maximum, then tell your customer that you have to reevaluate the overall cost together.

Answer 4

Other people's experience will probably vary, but one way I've seen it done is largely the same as your "traditional" with a couple of things to note:

1. Build in some overhead for changes (for example, 10%)
2. Assess and separately bill for large changes or aggregate and bill changes beyond the built-in cost (a good, albeit not programming, example is design work, where often the initial cost includes, say 3 revisions, and subsequent revisions or maybe total redos are extra)

Often, too, agile projects start out as a "core" item, and spiral out from there in a modular way on an as-needed basis (I've seen this happen quite a bit on the projects I've involved with). So, you start with a core product, let's say it's a mapping application. The first implementation is just a map that centers on your current location (what the customer initially ordered).

The customer then decides they want to have pin drops of certain attractions around you. Okay, that's a pretty big piece (relatively speaking), so you bill it as a new "module" or purchase order. Changes to things like the color or design of those pins are built into the cost of that order. Directions and overlays are another purchase order, since they weren't requested until after the other purchase order was underway, and so on and so forth.

Answer 5

Agile and 'Write an offer' seems like an antithesis :) - the latter is not productive software engineering :D

Okay, now that we have the joke out of the way - back to the real thing.

"How does it work in Agile?" - the contract complicates things but I hope to make it clear. Agile is founded on the prinicple of 'trust' and 'co-working' which means that the customer is allowed to change whatever, whenever and understands that it may cost a bit more or if non-intrusive, maybe for no extra cost.

What does this mean? It means that the contract spells out that we (the client) fix an initial estimate of cost and the +/- variance % that we can handle e.g. $100K bid but I'm willing to go up to $120K (this MAY not be part of the contract, but in the mind of the customer).

Now, when a design change comes in you go agile with the estimating and planning to - you get your team together and ask them the 'story point' estimate w.r.t. complexity of factoring the changes. Owing to some velocity estimate, you could multiply them and give a schedule estimate. It should be relatively easy to drive out the cost per story point if you know the team and their relative salaries (please don't average across EVERYONE's salary, you'll succumb to the flaw of averages).

Do you need to go back to the customer with the financials? NO. Not necessarily. You'll have the customer prioritize these and insert them at the correct place in the backlog. Now that you know the size of the backlog (you should if you don't already) and based on the financials (cost per story point) you know which low priority requirements may not be doable with the given budget. SHOW them the reprioritized backlog with the estimate of doable features as per $$ contract. Then let THEM decide if they are willing to pay more to get more if/when you/they get there. If they want it for free...you take a stand and TELL them it'll cost more.

This should help without you constantly going back with financials if you can have this graph up somewhere for the customer to see.

Hope this helps!