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

  • 1
    What you're describing is not a User Story; it's a Software Design Specification. You handle changes like this the same way you would handle any other new software development; you write a spec for it, agree on a price, do the work and send them a bill. – Robert Harvey Mar 17 '18 at 15:48
  • 1
    It's unclear what the problem is. You delivered a user story, as agreed; you certainly wouldn't change it retrospectively, that doesn't make any sense. Now there's a request for new functionality, a new user story. It doesn't matter whether or not that replaces or simply augments existing functionality; requirements change sometimes, that's why we use agile development methodologies. – jonrsharpe Mar 17 '18 at 15:51
  • "Cause the development team is paid according to accepted user stories, changing the existing story (already payed) would make it hard to calculate the payment." You can calculate the payment just fine by sticking "version 2" in the stories name. Don't feel like the first one failed. The first one pointed you to the second one. Heck I wouldn't feel bad about charging more for this one since striping out the old stuff to make room for version 2 is even more work. – candied_orange Mar 17 '18 at 16:48
  • @RobertHarvey reading the question, I understand that the user story would be something like "as a xxx I need a list of yyy satisfying <filter condition>, showing <columns> with lines having <highlighting condition> highlighted in red, so that I can see the work I have to do and focus on the most important priorities of the day". Is it forbidden to users to have a pretty clear idea of what they want in their stories ? – Christophe Mar 17 '18 at 22:52

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

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.