Well, whether or not this question gets migrated I figured I'd leave my opinion.
The Acceptance Criteria are chosen by the Product Owner, plain and simple. It's a way of formalizing what the Product Owner will need to see to be able to sign of on a story as being "complete."
How much detail the PO wants to put into that is therefore a product of the PO's work style, knowledge, etc. Many POs have UX training and would like to go so far as to define what it should look like. I think that's fine, as long as it works for your team. Others are mainly customer experts and leave the design up to the team.
Personally, I would encourage teams to formalize as much as can be thought of when looking at the story so that you minimize the number of conflicting assumptions between the team and PO.
However, in the end it's up to the team whether to accept a story into their sprint. They have every right (in Scrum, anyway) to say that the ACs are overly broad, overly prescriptive, infeasible, or too large to chew off in one sprint. Therefore, there is usually a lot of negotiation that happens between the team and the PO before agreeing on the ACs for each story.
But in the end, it's the Product Owner's call since she's the one who will be doing the "accepting." In general, Scrum says that it's the Product Owner's job to say what to build, and the team's job to say how to build it (and to actually do it). So really it's about what type of PO you want to be.
根据我的经验，马克的回答是关于 OP 列出的 AC 的适用性的金钱问题。然而，尽管这些标准是可以接受的，但我认为它们不足以减少 PO 在故事提交接受时期望产品做什么的模糊性。
除了列出的描述故事如何实施的 AC 之外，我还希望看到描述产品功能的 AC。例如，这些组对论坛用户和管理员是否可见？你如何定义“连接”？绑定用户和组的业务逻辑的细节是什么？故事是否涵盖了用户与组的“映射”和“取消映射”，或者是否将它们分开以使故事保持在可冲刺的规模内？
In my experience, Mark's answer is on the money about the suitability of the ACs listed by OP. However, though those criteria are acceptable, I suggest that they are insufficient to reduce ambiguity as to what the PO expects the product to do when the story is presented for acceptance.
In addition to the listed ACs which describe how the story will be implemented, I would expect to see ACs that describe what the product will do. For example, are those groups visible to forum users as well as the administrator? How do you define "connect"? What are the details of the business logic tying users and groups? Does the story cover both the "mapping" and "unmapping" of users to groups, or were they separated to keep the story within a sprintable size?
You may want to add acceptance tests to your user stories. My question may give you some perspective on how others approach user story specification.
I would describe the how the user interacts with the UI(ie UX) in the appropriate acceptance test, not the acceptance criteria. The criteria is better suited for input validation and other business rules that don't need to be covered in the higher level acceptance tests.
发布评论
评论（3）
好吧，无论这个问题是否被迁移，我想我都会留下我的意见。
验收标准由产品负责人选择，简单明了。这是一种形式化产品负责人需要看到的内容的方法，以便能够在故事上签名为“完整”。
因此，PO 想要投入多少细节是 PO 的工作风格、知识等的产物。许多 PO 接受过用户体验培训，并且愿意进一步定义它应该是什么样子。 我认为这很好，只要它适合您的团队。其他人主要是客户专家，将设计留给团队。
就我个人而言，我鼓励团队在查看故事时尽可能多地形式化，以便最大限度地减少团队和 PO 之间相互冲突的假设的数量。
但是，最终取决于团队是否接受故事进入他们的冲刺。他们完全有权利（至少在 Scrum 中）说 AC 过于宽泛、过于规范、不可行或太大而无法在一次冲刺中完成。因此，在就每个故事的 AC 达成一致之前，团队和 PO 之间通常会进行大量谈判。
但最终，这是产品负责人的决定，因为她是负责“接受”的人。一般来说，Scrum 认为产品负责人的工作是说明要构建什么，而团队的工作是说明如何构建（并实际执行）。所以实际上这取决于你想成为什么类型的 PO。
Well, whether or not this question gets migrated I figured I'd leave my opinion.
The Acceptance Criteria are chosen by the Product Owner, plain and simple. It's a way of formalizing what the Product Owner will need to see to be able to sign of on a story as being "complete."
How much detail the PO wants to put into that is therefore a product of the PO's work style, knowledge, etc. Many POs have UX training and would like to go so far as to define what it should look like. I think that's fine, as long as it works for your team. Others are mainly customer experts and leave the design up to the team.
Personally, I would encourage teams to formalize as much as can be thought of when looking at the story so that you minimize the number of conflicting assumptions between the team and PO.
However, in the end it's up to the team whether to accept a story into their sprint. They have every right (in Scrum, anyway) to say that the ACs are overly broad, overly prescriptive, infeasible, or too large to chew off in one sprint. Therefore, there is usually a lot of negotiation that happens between the team and the PO before agreeing on the ACs for each story.
But in the end, it's the Product Owner's call since she's the one who will be doing the "accepting." In general, Scrum says that it's the Product Owner's job to say what to build, and the team's job to say how to build it (and to actually do it). So really it's about what type of PO you want to be.
根据我的经验，马克的回答是关于 OP 列出的 AC 的适用性的金钱问题。然而，尽管这些标准是可以接受的，但我认为它们不足以减少 PO 在故事提交接受时期望产品做什么的模糊性。
除了列出的描述故事如何实施的 AC 之外，我还希望看到描述产品功能的 AC。例如，这些组对论坛用户和管理员是否可见？你如何定义“连接”？绑定用户和组的业务逻辑的细节是什么？故事是否涵盖了用户与组的“映射”和“取消映射”，或者是否将它们分开以使故事保持在可冲刺的规模内？
In my experience, Mark's answer is on the money about the suitability of the ACs listed by OP. However, though those criteria are acceptable, I suggest that they are insufficient to reduce ambiguity as to what the PO expects the product to do when the story is presented for acceptance.
In addition to the listed ACs which describe how the story will be implemented, I would expect to see ACs that describe what the product will do. For example, are those groups visible to forum users as well as the administrator? How do you define "connect"? What are the details of the business logic tying users and groups? Does the story cover both the "mapping" and "unmapping" of users to groups, or were they separated to keep the story within a sprintable size?
您可能想向您的用户故事添加验收测试。 我的问题可能会给您一些关于其他人如何做的看法方法用户故事规范。
我会在适当的验收测试中描述用户如何与 UI（即 UX）交互，而不是验收标准。该标准更适合输入验证和其他不需要在更高级别的验收测试中涵盖的业务规则。
You may want to add acceptance tests to your user stories. My question may give you some perspective on how others approach user story specification.
I would describe the how the user interacts with the UI(ie UX) in the appropriate acceptance test, not the acceptance criteria. The criteria is better suited for input validation and other business rules that don't need to be covered in the higher level acceptance tests.