在最近的几次迭代中，我总是意识到在客户开始使用APP之后我们错过了一些实现功能的用户故事细节。
例如：
原始要求是：＆＃34;可以将产品添加到迷你购物车（...添加产品的规则）＆＃34;
原始用户素材：＆＃34;可以将产品添加到迷你购物车（...添加产品的处理）＆＃34;
实际实施的功能：＆＃34;产品可以根据要求添加到迷你购物车中。但是在添加产品后重置所有过滤条件和刷新页面＃34;
客户希望它像：＆＃34;产品可以作为要求添加到迷你购物车中。在添加产品后保持当前过滤条件和刷新页面＃34;
我们收集了这些要求。 这些用户故事由我们的外包团队撰写。
我应该将此视为Bug或新用户故事，还是应该重新打开旧用户故事并编辑它以说明新请求？什么是最佳实践＆＃34;，每种方法的优缺点是什么？
非常感谢！
根据我的理解，业务要求总是简单， 用户故事总是小而抽象的。 有些时候，在开发人员开始编码和开发人员告诉我们之前，我们无法实现上述问题。 它是功能过程和技术问题，应该在开发阶段提交给开发人员讨论。所以我认为这是错误。
答案 0 :(得分：1)
用户故事故意保持简洁和抽象。原因是它被认为是“对话邀请”。这意味着当团队接近处理故事时，他们会与产品负责人交谈以开始充实故事的细节。这可能发生在积压改进中，也可能发生在sprint计划会话中。
我们的想法是在恰当的时间在故事中获得恰当的细节。因此，当开发人员开始编写故事时，他们相信他们已经足够了解产品负责人所要求的工作方式。
如果用户故事的细节不足，那么它就不会被认为是“准备好”进入冲刺阶段。这就是为什么开发团队和产品负责人如此密切合作，以便及时添加细节。
即使开发人员开始编写故事，他们仍然会经常与产品负责人交谈。例如，他们可能会模拟将产品添加到迷你购物车中，将其显示给产品负责人并检查以确保其符合他们的要求。
这个过程对Scrum至关重要。如果您发现需要重新编写故事，则表明该过程无法正常工作。在你的回顾中谈论它，并尝试找出如何最好地减少问题。
答案 1 :(得分：-1)
我在这里看到的是我们所谓的问题＆＃34; ready＆＃34;的定义对于一个故事，所以一个故事需要具备的标准才能被考虑用于计划和执行（例如INVEST：https://en.wikipedia.org/wiki/INVEST_(mnemonic)）。 我猜这个故事的正确qa从未完成过。在并置的团队中，这不是必需的，因为故事的目的实际上是建议与产品所有者进行对话，但对于离岸或外包开发，验证故事的准备定义始终是一种好的做法。
在您的具体情况下，我不会那么关注方法（错误或新故事），假设您不在ISO认证的组织中，您需要完成与您所说的相同的事情:)但更多关于向客户提供承诺价值的最快方式是什么。如果提出一个错误，修复它并部署修复程序是让客户满意的禁食方式。后来在回顾中提出这个问题并找到根本原因并解决问题。