我有兴趣了解人们如何处理流程级别用户故事接受标准的变更。
示例：
您编写了具有XYZ特征验收标准的用户素材。那 用户故事在1.0版本的sprint中实现。一段时间 之后的1.2版本产品所有者希望接受 标准不同（例如1分钟超时而不是30分钟 秒）。
你如何处理这种变化？它如何改变原始用户故事的状态？我们正在使用JIRA / JIRA Agile，如果您愿意，我会特别感兴趣重新打开您关闭的用户故事，并在新的Sprint中进行处理。
我们使用Confluence编写我们的产品规范，PS中的用户故事通过查询直接从JIRA加载。如果要更改原始用户故事的接受标准并重新打开它 - 如何确保1.0版的产品规范不会发生变化？
编辑：
我需要添加一些关于我们流程的更多信息：每个用户故事以及验收标准可以用来测试这些标准的一些步骤。这些步骤用于生成验证/测试协议，用于检查所有产品规格是否已正确实施。
现在这意味着对用户故事的更改将直接影响已经审核和签署的产品规范和测试协议，因为数据是通过jira查询加载的。我想这可能不是将内容拉入Confluence的适当方式，更持久的东西似乎是可取的。
即使我们没有使用这些直接/动态查询，问题仍然有效：需求/验收标准的变化如何影响用户故事？
答案 0 :(得分：2)
我认为这是一个新的用户故事，例如“作为一个用户，我希望将超时时间增加到1分钟，原因我自己知道”。
答案 1 :(得分：1)
因此，在产品发布后，产品负责人会回复您并表示他们希望：
1分钟超时而不是30秒
这可能被视为一个问题;这不是一个错误，因为超时工具工作正常，只是他们有一个问题的时期。因此，您可以创建一个问题，将其与原始故事相关联，然后将其分解为任务以实现此更改。
然而：
如何确保版本1.0的产品规范不会改变？
如果原始产品规格规定超时为30秒，但您现在已将其更改为一分钟，则无法避免规格已更改的事实。创建问题并将其链接到原始故事意味着您不需要编辑原始故事。
答案 2 :(得分：1)
谢谢大家的回答。我们已经找到了适合我们处理用户故事变化的方法。
我们最终得到的是以下原则/步骤：
这样我们就有了v1.0的产品规范，其中包含未更改的用户故事和v2.0的产品规范，其中包含更新的用户故事。
重要的事实是，多年后您可以获取任何版本的产品规格，并根据验收标准对其进行测试，并仍然获得通行证。如果原始用户故事已被修改，则情况并非如此。
我希望我能够足够清晰地解释这一点。如果我需要详细说明解决方案的任何部分，请告诉我。
答案 3 :(得分：0)
我会说你原来的故事仍然很好。鉴于超时更改有价值，您明确需要更改原始故事的验收标准。在您的测试自动化的情况下尤其如此。我会创建一个新故事：
作为一个 我想更改fraggle thrunge括号操作的超时值 那就是
写下这个新故事将使人们非常关注这一变化将带来的价值。如果没有增加任何价值，那么就不要这样做。
答案 4 :(得分：0)
一旦完成，您就无法更改用户故事的接受标准（是的，请参阅已完成的定义）。
如果产品所有者需要更改用户故事接受标准，则他/她必须使用“接受标准”创建新功能/用户故事。
如果更改已进入sprint的中间并且现有的Acceptance Criteria对项目没有任何意义，请从sprint backlog中删除用户故事并将其添加到 new （更改不应该在sprint中间接受sprint，带有新的/修改的验收标准。