Handle changes to completed user stories

Question

How can I handle change requests to already finished user-stories?

Let's say there is a user story which describes how the user wants to list entities. The story describes further:

• which information of the entities should be shown (as columns).
• under which conditions entities should be highlighted (background color)
• some filters

After estimating the effort based on story points, it has been implemented, accepted and shipped to the customer.

After working some time, the customer wants to replace the highlighting of entities with an expandable/collapsible grouping.

Cause the development team is payed according to accepted user stories, changing the existing story (already payed) would make it hard to calculate the payment.

Handling the requested changes separately on the other hand would make the existing story obsolete.

So can you give me some advice on how to handle this situation?

Kind regards

Answer 1

I understand that:

• you have delivered a release with a couple of user stories done, and in a way that it matches the definition of done.
• your relationship with the customer might however be less interactive and agile than I would expect (i.e. user describes stories in very much detail and accept them based on that detail, without benefiting from interaction with the team).
• a contractual setup formalises this relationship (fixed price per story?)
• the customer certainly expects the benefits from agile development despite the price based flavor of the contractual design (why else agree on a story based delivery model?).

Now the user changes his/her mind. This is normal in an agile context where we respond to change instead of blindly following a plan.

You need to check what is foreseen in the contract. But at first sight it looks like a new story to me: old story was delivered and accepted, and now a new delivery is expected based on a new input.

I believe that the customer is certainly ready to pay for the change (or at least will understand that he/she has to): there is no objective reason why the vendor shall bear the cost of the change in mind of the customer.

However the customer will certainly not accept to pay more than the incremental cost and will assume that you'll reuse the old parts that are reusable. So, if nothing is foreseen in the contract, the difficulty is to evaluate the SP taking into account that it's a change and not a totally new feature developed from scratch. To avoid ambiguity, it could help that the revised story refers to the already implemented feature (i.e. what is to be changed, instead of describing the full story as if it would be totally new).