Well, since it is a new requirement, treat it as a new feature request. Definitely not a bug.
EDIT: Since it is not clear who missed the detail either you or the customer, you can take both ways. If you forgot about it, then it is your bug. If the customer forgot to tell about it, then it depends. If it is a little fix, you can reopen the old story. If it is much work to be done, make it a new one.
P.S. Does it really matter how you do it? The point is just implement it like the customer asks, regardless of your internal terminology.
A Bug, a new User Story, reopening the old Story... is that really important? In any case, your customer is asking for a feature that is currently not implemented. So, as long as you can estimate its size and as long as he can prioritize it, it doesn't really matter how you call the way you capture the needs.
So, unless you have to deal with specific contractual constraints, just pick one solution, estimate the size and let the customer prioritize it (personally, I'd create a new user story).
I would say this should count as the old story. Your team should report reduced throughput (velocity) because of these changing requirements, especially if the original feature has not already shipped.
发布评论
评论（4）
好吧，既然这是一个新的需求，就把它当作一个新的功能请求。绝对不是一个错误。
编辑：由于不清楚您或客户谁错过了细节，因此您可以采取两种方式。如果你忘记了，那就是你的错误。如果客户忘记告知，那就要看情况了。如果有一点修复，你可以重新开始旧的故事。如果有很多工作要做，那就做一项新的。
PS 你怎么做真的很重要吗？重点是按照客户的要求实施它，无论您的内部术语如何。
（来源：oracle-guy.com)
Well, since it is a new requirement, treat it as a new feature request. Definitely not a bug.
EDIT: Since it is not clear who missed the detail either you or the customer, you can take both ways. If you forgot about it, then it is your bug. If the customer forgot to tell about it, then it depends. If it is a little fix, you can reopen the old story. If it is much work to be done, make it a new one.
P.S. Does it really matter how you do it? The point is just implement it like the customer asks, regardless of your internal terminology.
(source: oracle-guy.com)
一个 Bug、一个新的用户故事、重新打开旧的故事……这真的很重要吗？无论如何，您的客户要求的功能目前尚未实现。所以，只要你能估计它的大小，只要他能确定它的优先级，你如何调用捕捉需求的方式并不重要。
因此，除非您必须处理特定的合同约束，否则只需选择一种解决方案，估计规模并让客户确定其优先级（就我个人而言，我会创建一个新的用户故事）。
A Bug, a new User Story, reopening the old Story... is that really important? In any case, your customer is asking for a feature that is currently not implemented. So, as long as you can estimate its size and as long as he can prioritize it, it doesn't really matter how you call the way you capture the needs.
So, unless you have to deal with specific contractual constraints, just pick one solution, estimate the size and let the customer prioritize it (personally, I'd create a new user story).
我会编辑旧故事来记录修改。否则你可能会在新故事和旧故事之间出现矛盾。
如果客户改变了主意，这很难被视为缺陷（或错误）。
务实：估计、安排、实施。
I would edit the old story to document the modification. Otherwise you may have contradictions between the new story and the old one.
This can hardly be considered as a defect (or bug) if the customer changed its mind.
Be pragmatic: estimate it, schedule it and implement it.
我想说这应该算是老故事了。由于这些不断变化的需求，您的团队应该报告吞吐量（速度）降低，尤其是在原始功能尚未发布的情况下。
I would say this should count as the old story. Your team should report reduced throughput (velocity) because of these changing requirements, especially if the original feature has not already shipped.