用户故事验收标准示例

我有以下用验收标准的用户故事示例。用户故事验收标准示例

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

这是我的例子：

用户案例：

作为论坛的管理员我将连接的人以群分，让人们可以组织起来。

验收标准：

人员组的创建会发生以下的人组池（人组池是一个对象也是在当前的软件系统在视觉上有售）
创建发生在persongroup池的上下文菜单中。在池下面可以创建新的组。
一个人组包含：人组ID，描述，此言

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

亲切的问候，启。

来源

2011-11-14 Kai Kramhoeft

嗨启，欢迎来到StackOverflow！这个问题实际上对于本网站的任务来说有点偏离主题，这是关于回答特定的*编程*问题的。我建议将它移植到[程序员StackExchange站点]（http://programmers.stackexchange.com/faq）。 –

这个问题是脱离主题，因为它不在本网站的范围内，如[我可以在这里询问什么主题？]（// stackoverflow.com/help/on-topic）中定义的。另请参阅：[什么类型的我应该避免提问？]（// stackoverflow.com/help/dont-ask）您可以在[另一个Stack Exchange站点]（// stackexchange.com/sites#name）上询问，例如[pm。 se]或[softwareengineering.se]。请务必阅读帮助中心中针对您打算发布问题的任何网站的主题页。 – Makyen

我投票结束这个问题作为题外话，因为它不是关于编程。 – TylerH

那么，不管这个问题是否被迁移，我想我会留下我的意见。

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

PO想要投入多少细节因此是PO的工作风格，知识等的产物。许多PO都有UX培训，并且希望进一步定义它的外观。 我认为这很好，只要它适合你的团队。其他人主要是客户专家，并将设计留给团队。

就我个人而言，我会鼓励团队在观察故事时尽可能多地形式化，以便尽量减少团队与采购订单之间相互冲突的假设数量。

但是最终由团队决定是否接受故事进入他们的冲刺。无论如何，他们都有权利（在Scrum中）说AC太宽泛，过于规范，不可行，或者太大而不能在一次冲刺中咀嚼。因此，在就每个故事达成一致之前，团队和采购订单之间通常会进行很多谈判。

但是，最终，产品负责人呼吁，因为她会做“接受”。一般来说，Scrum说产品负责人的工作就是说要建立什么，并且团队的工作要说如何建立它（以及实际完成它）。所以真的是关于你想成为什么类型的采购订单。

来源

2011-11-14 05:17:54

根据我的经验，马克的回答是关于OP列出的AC适用性的钱。然而，尽管这些标准是可以接受的，但我建议他们不足以减少PO在产品被接受时期望产品做什么的模糊性。

除了列出的AC其描述如何的故事将被执行，我希望看到的AC描述什么产品做。例如，这些组对论坛用户和管理员都是可见的吗？你如何定义“连接”？业务逻辑与用户和组织绑定的细节是什么？这个故事是否涵盖了用户对群组的“映射”和“解除映射”，还是将它们分开以保持故事的可扩展大小？

来源

2012-02-06 04:23:38

您可能希望将验收测试添加到用户故事中。 My question可能会给你一些关于他人如何处理用户故事规范的观点。

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

来源

2013-10-22 19:19:37 Brenden

用户故事验收标准示例

回答

相关问题