Changes to the user story after the sprint has started

Question

What types changes/additions/further clarifications do you think are ok to make to a user story?

what changes/additions/further clarifications do you think are not ok to have happen to the user story?

Answer 1

You can cancel a sprint. Or possibly move the troublesome items to a new sprint perhaps? Thereby reducing the length of the current sprint. But in essence I say, anything that affects the length or the output of the sprint drastically would be our decision point. Only you can really asses that I would say.

Answer 2

The point of a user story is to define a feature that's valuable to the customer. If any aspect of that definition changes, you'd better change the story.

On the other hand, your story point estimates were based on the old story and old acceptance criteria - if changes to a user story dramatically increase the time it takes to complete it, you'll have to split the story and move part of it (or another lower-priority story) into another sprint.

It also depends how close you are to the end of the sprint - if tomorrow's the last day of the sprint, just make a new story to express the changes and add the new story to the next iteration (or the one after that, depending on its urgency).

Answer 3

What types changes/additions/further clarifications do you think are ok to make to a user story (after a sprint has started)?

Any that the Product Owner asks for and for the Scrum team still to be comfortable to maintain their commitment to completing all user stories commited to in the sprint.

what changes/additions/further clarifications do you think are not ok to have happen to the user story (after a sprint has started)?

Any that the Product Owner asks for and make the Scrum team not comfortable to maintain their commitment to completing all user stories commited to in the sprint.

Answer 4

As I recently referenced in response to another stack overflow question, I think Martin Fowler's blog post on Conversational Stories is a good one for answering questions about user stories.

Clarifications should always be welcome as part of the conversation. Changes that do not change the overall story should be permitted if the team feels it has time to complete the requested changes in the current sprint. And additions should generally be new stories unless the team feels they have the time and it would be easier for them to do it during the current sprint.

So the overall answer, is "it depends", but I think using the above guidelines will help everyone make the best decision for the team.

Answer 5

I think this all depends on the team negotiating with the product owner. In a way, ANY changes to a user story which affect the implementation of the story are not okay.

What the team committed to was the user story as it was specified during sprint planning. Any changes introduced later were not part of the commitment, so the Product Owner (assuming that this is where the changes are coming from) should be aware that any requirement changes need to be signed off by the team.

Then again, this is a very restrictive way of handling this.

For a more real-world answer, I'd say that any changes to the user story need to be brought up to the team and negotiated. The team should be able to estimate the extra time needed to implement the changes and based on this commit to the changed user story or not. If these are little changes it's likely that you can just add the workload to the running sprint without any risks. If it's more effort, come up with a solution that doesn't put the sprint at risk and is agreed upon by the team and product owner. These could be:

1. Leave out another user story or reduce the scope of another user story.
2. Try to fit everything in but have a list of optional tasks that you can leave out if the time runs out.
3. Add resources to the team. Let the sprint run a few days longer.
4. Write a new user story for the changes and prioritise it so that it gets into the next sprint.
5. Drop the changed user story for this sprint, rewrite the user story and do it in the next sprint.

Even if the changed requirements pop up because the original requirements proved to be "wrong" in some way, I still think that what the team committed to is what counts. So in the case that the Product Owner decides that the user story as is has no value and needs to be changed, this is not a valid reason to bring all the changed requirements into the sprint. If the effort to apply the changes would put the rest of the sprint at the risk of failing, the better option would be to drop the changed story for this sprint and bring it up again with the changes during the next sprint planning.