Changes to the user story after the sprint has started [closed]

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

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 2

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.