Scrum论坛

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

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

传统上，史诗只是一个故事，还没有分解成更小的工作片段，可以在一次迭代中交付。在XP(用户故事的起源)中，如果一个用户故事的实现和交付时间过长，那么必须在开始工作之前分解它。在Scrum中，你可以在适合一个Sprint的精炼产品待办事项中看到这一点。

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

是否以及如何使用验收标准取决于你所使用的Epic的定义。

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

这取决于Epic对你的公司意味着什么。我曾见过Epics被用于一个定义松散的新功能，如“添加将总账导出为可用于创建电子表格的格式的能力”，但我也曾见过Epics被用于“每周增加10%的日活跃用户数量”。当前一个陈述在使用什么格式时模棱两可时，后一个陈述作为接受标准是足够清楚的。

情况因情况而异，就像所有敏捷的事情一样，对于正确的事情并没有严格的规则。我甚至拒绝提及最佳实践。我真的不喜欢这个词。没有最佳实践，只有一大堆值得考虑的好想法。

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

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

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

在Scrum中，返工既是必要的，也是需要的，因为它是经验主义和学习的结果。例如，史诗可能无法被很好地理解，而清晰度将是突发性的。产生信任的是持续的交付，而不是规范中的细节。当需要信任时，往往过早地求助于详细的规范缺席．也许应该从这个角度来看待接受标准的细节。

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

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

我同意一个充满容器的产品Backlog是没有用的。但是，如果您使用史诗作为容器，与该容器相关联的各个故事难道不会为容器创建接受标准吗?产品待办事项列表在Scrum指南中是这样定义的

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

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

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

因此，一旦一个Epic被分解成一个或多个特性，我们是否应该从产品待办事项列表中删除这个Epic ?验收标准将在每个基本特性中?

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

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

据推测，这也避免了重复或两次(或三次)估算史诗、功能和故事级别的问题。

容器可以保留在产品待办事项列表中，甚至可以在该容器的所有工作完成后移动到完成。这完全取决于使用容器的原因和方式。来自产品Backlog的团队是唯一能够回答您最后问题的人。

Scrum指南规定了产品负责人的责任如下:

产品负责人负责通过Scrum团队的工作使产品的价值最大化。在不同的组织、Scrum团队和个人之间，如何实现这一点可能存在很大差异。

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

• 制定并明确传达产品目标;

• 创建并清晰地沟通产品待办事项列表项目;

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

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

Scrum指南在Scrum管理员的职责中明确了这一点

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

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

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

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

我的观点是:

- Epic是一种对用户故事进行分组的方法

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

-用户故事可以呈现自己，这实际上是一个需要分解的史诗。

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

史诗有什么价值?

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

有不同的视角@Ruth Russell。

史诗(@Thomas Owens分享)是简单的用户故事，它们太大了，不能在一次迭代中完成(无论它是什么——就像我们在谈论Scrum一样——我们将使用sprint)。正如ian Mitchell所说:“为一部‘史诗’设定接受标准改善透明度“如果是这样的话，那太好了，这正是我希望他们这样做的目的。

如果我们看看AC的实际是什么:客户(在Scrum的情况下，PO)将评估故事的完整性的标准(为用户)——这使故事(Epic)更加清晰，或者如Ian所说，提高了透明度，为什么不添加AC的.... or……史诗级别的CoS是否足够?

我正在为我的新项目建立产品Backlog，我也不清楚Epics是否应该有验收标准。根据我的理解，epic是更大的用户故事，不能在一个Sprint内完成，需要被分解。

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

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

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

你可以把接受标准看作是代表某种程度的完成．一定有一个已完成的定义它适用于增量，但它不一定是一个整体的承诺。请记住，在精益和敏捷实践中检查和调整的最佳方法是尽可能贴近正在执行的工作的时间和地点。

验收标准有时被称为故事完成．你可以合理地得到更高水平的完成，比如录取标准，在一个史诗级的水平。拥有多个级别的Done可以帮助及时地确保质量，并且可以减少未完成增量的风险。

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

谢谢你的澄清。

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

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