用户故事的验收标准示例

Question

对于具有验收标准的用户素材，我有以下示例。

我想知道是否允许我描述如何更改GUI以支持新功能。

这是我的例子：

用户故事：

• 作为论坛管理员，我将分组人员，以便人们可以组织起来。

接受标准：

1. 人员组的创建发生在人员组池下方（人员组池也是当前软件系统中可视化的对象）
2. 使用persongroup池的上下文菜单进行创建。在游泳池下方可以创建新组。
3. 一个人群包含： 人组ID， 描述， 备注

可能与正确的验收标准相关吗？

亲切的问候， 启。

Answer 1

好吧，无论这个问题是否被迁移，我都认为我会留下我的意见。

验收标准由产品负责人选择，简单明了。这是一种形式化产品负责人需要看到的能够将故事签名为“完整”的方式。

PO想要投入多少细节因此是PO的工作方式，知识等的产物。许多PO都有UX培训，并希望定义它应该是什么样子。 我认为这很好，只要它适用于您的团队。其他人主要是客户专家，并将设计留给团队。

就个人而言，我会鼓励团队在查看故事时尽可能多地进行正式化，以便最大限度地减少团队与PO之间相互冲突的假设数量。

然而，最终由团队决定是否接受他们冲刺的故事。他们完全有权（在Scrum中，无论如何）说AC在一个冲刺中过于宽泛，过于规范，不可行，或者太大而无法咀嚼。因此，在为每个故事商定AC之前，团队和PO之间通常会进行很多谈判。

但最终，这是产品负责人的电话，因为她是那个“接受”的人。一般来说，Scrum说产品所有者的工作是说要构建什么，团队的工作是说 如何构建它（以及实际做到这一点）。所以真的是你想成为什么类型的PO。

Answer 2

根据我的经验，马克的回答是关于OP所列AC的适用性。然而，虽然这些标准是可以接受的，但我认为它们不足以减少PO在展示接受时期望产品做什么的模糊性。

除了列出如何故事的列出的AC之外，我希望看到AC描述产品将会做什么 。例如，论坛用户和管理员可以看到这些组吗？你如何定义“连接”？绑定用户和组的业务逻辑的详细信息是什么？这个故事是否涵盖了用户对群组的“映射”和“取消映射”，还是将它们分开以使故事保持在可拼写的范围内？

Answer 3

您可能希望为用户素材添加验收测试。 My question可以让您了解其他人如何处理用户故事规范。

我将在适当的验收测试中描述用户如何与UI（即UX）进行交互，而不是验收标准。该标准更适合于输入验证和其他业务规则，不需要在更高级别的验收测试中涵盖。