EPIC接受标准?

对“史诗”有接受标准吗?改善透明度“完成”意味着什么?

史诗对你的组织意味着什么?

传统上，史诗只是一个故事，还没有被分解成更小的作品，可以在一次迭代中交付。在XP(用户故事的起源)中，一个需要很长时间来实现和交付的用户故事必须在工作开始之前被分解。在Scrum中，你可以在适合一个Sprint的细化产品待办事项项中看到这一点。

然而，有些人使用Epic来引用其他工作的容器，以达到跟踪的目的。当一部史诗中的所有工作都完成时，它就是完整的。今天，这经常出现在一些工具(如Jira)处理所谓“史诗”问题的方式中。

如果以及如何使用验收标准取决于你使用的史诗的定义。

添加到什么@托马斯·欧文斯说到用户故事，在XP中他们最初不包含接受标准。这是后来加上来帮助理解故事的东西。

这取决于Epic对你的公司意味着什么。我曾见过将epic用于一个新功能，如“添加将总账导出为可用于创建电子表格的格式的能力”，但我也曾见过将epic用于一个计划，如“每周增加10%的日活跃用户数量”。后一种说法作为接受标准是足够清楚的，而前一种说法在使用何种格式方面存在不确定性。

情况因发生而异，与所有敏捷的事情一样，没有严格的规则来确定什么是正确的事情。我甚至拒绝提及最佳实践。我真的不喜欢这个词。没有最佳实践，只有大量值得考虑的好想法。

有趣的话题……但这让我觉得，在史诗级别上不包含接受标准会产生一个整体，让我解释一下原因:

如果我们使用史诗作为没有验收标准的未来工作的容器，那么我们正在生成返工，因为团队如何在不考虑如何完成工作和不考虑可以代表的工作的情况下，尝试理解完整的backlog并构建路线图的主要版本呢?此外，我们可能会打开一扇门，不识别所需的依赖项和/或输入。

为了结束我的观点，我们应该考虑构建一个包含接受标准的Epic，拥有一个带有“容器”的待办事项并不能产生信任。

在Scrum中，由于经验主义和学习而产生的返工是必要的，也是被期待的。例如，史诗可能不能很好地理解，而清晰度将会出现。产生信任的是持续的交付，而不是规范中的细节。当信任存在时，人们往往过早地求助于详细的规范缺席．接受标准的细节也许应该从这个角度来看待。

如果我们使用史诗作为没有验收标准的未来工作的容器，那么我们正在生成返工，因为团队如何在不考虑如何完成工作和不考虑可以代表的工作的情况下，尝试理解完整的backlog并构建路线图的主要版本呢?此外，我们可能会打开一扇门，不识别所需的依赖项和/或输入。

为了结束我的观点，我们应该考虑构建一个包含接受标准的Epic，拥有一个带有“容器”的待办事项并不能产生信任。

我同意一个充满容器的产品Backlog是没有用的。但是如果您使用史诗作为容器，那么绑定到该容器的单个故事是否会为容器创建验收标准?产品待办事项列表在Scrum指南中是这样定义的

产品待办事项列表是一个紧急的、有序的清单，列出了改进产品所需要的东西。它是Scrum团队所承担的唯一工作来源。

基于这种说法，我不认为epic -as-containers是产品待办事项列表的一部分，因为它们没有描述任何工作。它们只是一种以组织/团队可以看到关系的方式将实际工作关联在一起的方法。

如果你实际上是在创建包含工作描述的史诗，接受标准就会很有用。但如果是这样的话，我认为你的史诗实际上是用户故事，其中一些对于单个Sprint来说可能太大了。

那么，一旦Epic被分解为一个或多个功能，我们是否应该从产品待办事项列表中删除Epic ?验收标准将在每个潜在的功能?

类似地，一旦一个特性被分解成一个或多个故事，我们是否应该从backlog中删除该特性?接受标准将在每个故事中?

在适当的时候，我们应该从产品待办事项列表中删除所有的“容器”吗?

可以推测，这也避免了分别在史诗级、特征级和故事级进行重复或两次(或三次)估算的问题。

容器可以保留在产品待办事项列表中，甚至可以在该容器的所有工作完成后移动到“完成”。这完全取决于您为什么以及如何使用容器。根据产品待办事项列表工作的团队是唯一能够回答您最后一个问题的人。

Scrum指南规定了产品负责人的职责:

产品负责人负责使Scrum团队的工作所产生的产品价值最大化。如何做到这一点在组织、Scrum团队和个人之间可能有很大的不同。

产品负责人还负责有效的产品待办事项管理，包括:

• 开发并明确传达产品目标;

• 创建并清楚地沟通产品待办事项项;

• 订购产品待办事项列表项;而且,

• 确保产品待办事项列表是透明、可见和可理解的。

Scrum指南在Scrum Master的职责中阐述了这一点

TScrum Master以多种方式为产品负责人服务，包括:

• 帮助寻找有效的产品目标定义和产品待办事项管理技术;

• 帮助Scrum团队理解对清晰简洁的产品待办事项列表项的需求;

产品负责人和Scrum Master应该一起寻找有效的方法来管理产品待办事项列表。产品负责人可以做出这些决定，但优秀的产品负责人会让Scrum团队的其他成员参与讨论，讨论他们认为如何最好地利用产品待办事项列表为团队服务。

我的观点是:

史诗是一种分组用户故事的方式

如果你把用户故事分成史诗，那么史诗中用户故事的完成意味着史诗的完成。每个用户故事都有接受标准，因此当用户故事“关闭”时，史诗就完成了。

一个用户故事本身可以是一个需要分解的史诗。

-如果你开始使用史诗，就会出现将用户故事分组到史诗中的负担。

史诗有什么价值?

我很有兴趣听听OP对他在《史诗》中使用接受标准的组织的经验有什么看法。对我来说，这似乎是一种浪费;接受标准在故事中，史诗只是一种分类。

有不同的观点@Ruth Russell。

史诗(@Thomas Owens分享的)只是用户故事，太大了，不能在一次迭代中完成(不管它是什么——因为我们在谈论Scrum——我们将使用冲刺)。就像@Ian Mitchell说的“对一部‘史诗’有接受标准吗?改善透明度如果是这样的话，那太好了，这就是我希望他们会做的事情。

如果我们看看AC实际上是什么:客户(在Scrum中是PO)评估故事的完整性的标准，以及故事实际应该(为用户)做的事情——这使故事(Epic)变得清晰，或者，如Ian所说，提高了透明度，为什么不添加AC的....或……史诗级别的CoS足够吗?

我刚刚为我的新项目建立了产品待办事项列表，我也很困惑史诗是否应该有验收标准。根据我的理解，史诗是更大的用户故事，不能在1个Sprint内完成，需要分解。

假设我们在分解史诗时提到了史诗和用户故事的接受标准。史诗的接受标准是否有可能与用户故事不同，因为我们在分解用户故事时可能有更多的信息。

难道我们不需要改变史诗的接受标准吗?

我正在考虑只在用户故事级别设置验收标准。

您可以将接受标准看作代表某一级别的完成．一定有一个完成的定义这适用于增量，但这并不一定是一个单一的承诺。请记住，在精益和敏捷实践中检查和调整的最佳方法是尽可能接近正在执行的工作的时间和地点。

接受标准有时被称为故事完成．你可以合理地得到更高层次的完成，例如接受标准，在史诗级别。拥有多个完成级别可以帮助及时地确保质量，并且可以减轻未完成增量的风险。

在最初的帖子发布后的1.5年里，我对这个问题的看法没有改变。然而，我想指出的是，这整个对话实际上与Scrum无关，因为用户故事和史诗在Scrum指南的任何地方都没有提到。用户故事是一种起源于极限编程(XP)的实践，已被许多组织改编和采用。“正确的方式”是每个组织自己决定的。

谢谢你的澄清。

我同意史诗在分解后只是一个故事的容器。我总是说史诗的接受标准是故事。我认为，当一组业务期望的功能完成时，用史诗来构建你的产品定义是有很大好处的。

是的，是的，史诗是涌现的。这是我们如何定义乘积的一部分。如果你创建了一个史诗，并列出了一些接受标准作为起点，那么接受标准通常就是你需要为史诗解构创造的故事。想法通过解构产生，最终史诗作为产品交付的功能出现。