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.
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:
Leave out another user story or reduce the scope of another user story.
Try to fit everything in but have a list of optional tasks that you can leave out if the time runs out.
Add resources to the team. Let the sprint run a few days longer.
Write a new user story for the changes and prioritise it so that it gets into the next sprint.
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.
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).
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.
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.
发布评论
评论（5）
产品负责人要求和Scrum 团队仍然轻松维持完成所有用户故事的承诺短跑。
产品负责人提出的任何要求都会让 Scrum 团队不舒服继续完成冲刺中承诺的所有用户故事。
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.
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.
我认为这一切都取决于团队与产品负责人的谈判。在某种程度上，对用户故事的任何影响故事实施的更改都是不好的。
团队致力于的是在冲刺计划期间指定的用户故事。稍后引入的任何更改都不是承诺的一部分，因此产品负责人（假设这是更改的来源）应该意识到任何需求更改都需要由团队签署。
话又说回来，这是一种非常严格的处理方式。
对于更现实的答案，我想说对用户故事的任何更改都需要提交给团队并进行协商。团队应该能够估计实施更改所需的额外时间，并基于是否提交更改的用户故事。如果这些变化很小，那么您可能只需将工作负载添加到正在运行的冲刺中，而不会有任何风险。如果需要付出更多努力，请提出一个不会使冲刺面临风险并且得到团队和产品负责人同意的解决方案。这些可能是：
即使因为原来的需求在某种程度上被证明是“错误的”而出现了更改的需求，我仍然认为团队所承诺的才是最重要的。因此，如果产品负责人认为用户故事本身没有价值并且需要更改，那么这并不是将所有更改的需求带入冲刺的有效理由。如果应用更改的努力会使冲刺的其余部分面临失败的风险，那么更好的选择是放弃本次冲刺的已更改故事，并在下一个冲刺计划期间再次将其与更改一起提出。
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:
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.
用户故事的重点是定义对客户有价值的功能。如果该定义的任何方面发生变化，您最好改变故事。
另一方面，您的故事点估计是基于旧故事和旧接受标准 - 如果对用户故事的更改大大增加了完成它所需的时间，您将不得不拆分故事并移动其中的一部分（或另一个优先级较低的故事）进入另一个冲刺。
它还取决于您距离冲刺结束的时间有多近 - 如果明天是冲刺的最后一天，只需制作一个新故事来表达更改并将新故事添加到下一个迭代（或之后的迭代，具体取决于其紧迫性）。
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).
正如我最近在回答另一个堆栈溢出问题时提到的那样，我认为 Martin Fowler 关于 对话故事 非常适合回答有关用户故事的问题。
作为对话的一部分，澄清应该始终受到欢迎。如果团队认为有时间完成当前冲刺中请求的更改，则应该允许不改变整体故事的更改。添加通常应该是新的故事，除非团队觉得他们有时间并且在当前的冲刺期间更容易做到这一点。
所以总体答案是“这取决于”，但我认为使用上述指南将帮助每个人为团队做出最佳决定。
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.
您可以取消冲刺。或者可能将麻烦的项目转移到新的冲刺中？从而减少当前冲刺的长度。但本质上我想说的是，任何对冲刺的长度或输出产生巨大影响的因素都将是我们的决策点。只有你才能真正评估我所说的。
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.