敏捷史诗故事是什么

What has not been declared dead already? Test Driven Development was buried years ago. Still, it continues to spread. Of course, Agile is dead as well. But even traditional companies come into contact with Scrum. The dead continue to live, but declaring something dead is always good for a snappy headline. In that sense, witness how I destroy epics as an agile practice.

尚未宣布死亡的是什么？ 测试驱动开发几年前就被埋葬了 。 尽管如此，它仍在继续传播。 当然， 敏捷也死了。 但是，即使是传统公司也开始接触Scrum。 死者继续活着，但是宣布死者总是一个活泼的标题。 从这种意义上讲，见证我如何通过敏捷实践销毁史诗。

什么是史诗？ (What are epics?)

The term is vague. This has advantages. Epics are more for communication than specification. The vagueness makes them versatile. But there is a risk of misunderstandings. I stick to Mike Cohn’s definition:

这个词含糊不清。 这具有优势。 史诗更多是为了交流而不是规范。 模糊性使它们变得通用。 但是存在误解的风险。 我坚持迈克·科恩的定义：

A Scrum epic is a large user story. (Source)

Scrum史诗是一个大用户故事。 ( 来源 )

I use the term like this: An epic is a story that is too big to be implemented in a Scrum sprint. The items at the top of the Product Backlog are thus not epics, but little stories. Down in the backlog you will typically find epics. Over time, the epics are “sliced” into stories that can be pulled into a sprint.

我用这样的术语：史诗是一个故事，太大了，无法在Scrum冲刺中实现。 因此，产品待办事项列表顶部的项目不是史诗，而是小故事。 在待办事项列表中，您通常会找到史诗。 随着时间的流逝，这些史诗被“切成”故事，这些故事可以拉入冲刺。

That is what I have taught for years in my training courses. It seems to be the general consensus. Intuitive at first glance. I’m here to explain why it’s not practical.

这就是我多年来在培训课程中所教的内容。 这似乎是普遍共识。 乍一看很直观。 我在这里解释为什么它不实用。

处理史诗的3种不切实际的方式 (3 impractical ways to deal with epics)

So far, I’ve come across three ways companies deal with epics. None of them is practical. Let’s call them:

到目前为止，我遇到了公司处理史诗的三种方式。 它们都不实用。 我们称它们为：

溶出度 (Dissolution)

链接 (Links)

树木 (Trees)

1.解散 (1. Dissolution)

The principle of dissolution is simple. An epic is completely broken down into its components, the individual little stories.

溶解原理很简单。 史诗被完全分解为各个小故事。

For example, an epic “Book flight” of an online flight portal can be broken down into the individual process steps. So “Log in”, “Search flight”, and so on. Every process step becomes a story. The team estimates the story. As long as it is too big, the team continues to slice it. Once all stories are small enough to fit into sprints, the team deletes the epic and starts development for the stories.

例如，在线航班门户网站的史诗般的“预订航班”可以细分为各个流程步骤。 因此，请“登录”，“搜索航班”等。 每个过程步骤都是一个故事。 团队估计了这个故事。 只要太大，团队就会继续切分。 一旦所有故事都足够小以适合冲刺，团队便删除史诗并开始为故事进行开发。

It’s the underlying idea of completeness that bothers me. The dissolution suggests that a topic can be completed with a predetermined scope. But if changes to the stories are possible during development, you can’t define all the stories upfront.

完整性的根本思想困扰着我。 解散表明主题可以在预定范围内完成。 但是，如果在开发过程中可以对故事进行更改，则无法预先定义所有故事。

The Scrum Guide says:

Scrum指南说：

A product backlog is never complete. […] Requirements never stop changing.

产品积压工作从未完成。 […]需求永不停止改变。

If you have to deliver a fixed scope, stop pretending. Forget about epics, and describe the detailed requirements upfront. Just don’t claim to be agile then.

如果必须提供固定范围，请停止假装。 忘记史诗，并预先描述详细的要求。 只是不要声称自己那么敏捷。

2.链接 (2. Links)

If you don’t dissolve your epics completely, it makes sense to use links. The epics remain, down in the backlog. You link new little stories to the epics from which they derive.

如果您没有完全解散史诗，那么使用链接很有意义。 史诗仍然存在，积压下来。 您将新的小故事链接到它们衍生的史诗。

The risk is that over time, the amount of epics increases. The backlog becomes bloated. It contains epics that you don’t need any more. The stakeholder is no longer in the company. Or the topic is no longer relevant.

风险在于，随着时间的流逝，史诗的数量会增加。 积压变得becomes肿。 它包含您不再需要的史诗。 利益相关者不再在公司中。 或主题不再相关。

Of course, you can clean up your backlog from time to time. I regard this as non-value-added work. And you can avoid it, as I will describe later.

当然，您可以不时清理积压的订单。 我认为这是非增值工作。 您可以避免它，正如我稍后将描述的那样。

3.树木 (3. Trees)

Another way is the depiction of epics and stories as a tree:

另一种方式是将史诗和故事描绘成一棵树：

You group the little stories by epic. Not a bad idea. But what you lose is the ordered list of the backlog. How do you determine the implementation order then?

您将小故事按史诗分组。 不错的主意。 但是，您丢失的是积压的有序列表。 您如何确定执行顺序？

Of course you can use a digital tool that supports both views. The risk: you invest too much time and effort in the tools. What are the views? What are the attributes? What is the underlying data model? Interesting questions. But in an agile approach they should not have high priority.

当然，您可以使用支持两种视图的数字工具。 风险：您在工具上投入了太多时间和精力。 有什么看法？ 有哪些属性？ 什么是基础数据模型？ 有趣的问题。 但是，在敏捷方法中，它们不应具有较高的优先级。

In summary, the idea of grouping is good. But doing it is time-consuming.

总而言之，分组的想法很好。 但是这样做很耗时。

史诗的替代品 (The alternative to epics)

There has long been an alternative. It is even mentioned in the same blog post by Mike Cohn, which I linked above.

长期以来一直存在替代方案。 我在上面链接的Mike Cohn的同一篇博客文章中甚至提到了这一点。

I am talking about themes.

我在谈论主题 。

A theme can be thought of as an additional attribute of the stories. Normally, several stories share the same theme. The story “Search flight” could have the theme “Book flight”. A snippet from the backlog could look like this:

可以将主题视为故事的附加属性。 通常，几个故事具有相同的主题。 故事“搜索航班”的主题可能是“图书航班”。 待办事项清单中的代码段可能如下所示：

Themes are not managed as separate backlog elements. This eliminates the cleanup work discussed in the Links chapter. That’s good.

主题不作为单独的待办事项元素进行管理。 这消除了“链接”一章中讨论的清理工作。 非常好。

But what you lose is the process of gradual refinement from the big epics to the stories that can be implemented in a sprint. That’s bad.

但是，您失去的是从大史诗到可以在冲刺中实现的故事的逐渐完善的过程。 那很糟。

Luckily, there are practices that make it possible to do this refinement outside of the backlog. One way to identify themes is a use case diagram:

幸运的是，有些实践可以在积压之外进行改进。 识别主题的一种方法是用例图：

The nice thing about such diagrams is that they show the “Big Picture” due to the high level of abstraction and the graphical representation. For that, a backlog is unsuitable.

这样的图的好处是，由于高度的抽象和图形表示，它们显示了“大图”。 为此，积压是不合适的。

The use case names later become themes in the backlog. But how do you get from the use cases to the stories? For this, Jeff Patton's Story Mapping is a good fit:

用例名称随后成为待办事项中的主题。 但是您如何从用例到故事呢？ 为此，Jeff Patton的故事映射非常适合：

The top two lines of the example map show the use cases “Book flight” and “Manage profile” and their basic flow. Under the individual steps, the team hangs the alternatives: other processes, errors and so on. These yellow notes are called user tasks.

示例图的前两行显示了用例“预定排期”和“管理个人资料”及其基本流​​程。 在各个步骤下，团队会挂起其他选择：其他流程，错误等。 这些黄色笔记称为用户任务。

In Backlog Refinement, the team derives the stories from the user tasks. A task can serve as the title of the story. The team adds details like acceptance criteria to the stories.

在“积压细化”中，团队从用户任务中得出故事。 任务可以充当故事的标题。 团队在故事中添加了诸如接受标准之类的细节。

后果 (The consequences)

Applying this alternative approach has consequences. For example, the Product Backlog will only contain stories for the next 1–2 sprints. So maybe 10–20 stories.

应用此替代方法会产生后果。 例如，产品待办列表将仅包含接下来的1-2个冲刺的故事。 大概有10到20个故事。

All activities like further prioritization, estimation and elaboration of the acceptance criteria only take place with these stories. As the 10th agile principle says:

所有活动，如进一步确定优先顺序，评估和确定接受标准，都仅在这些故事中进行。 正如第十个敏捷原则所说：

Simplicity — the art of maximizing the amount of work not done — is essential.

简洁-最大化未完成工作量的艺术-是必不可少的。

If management wants to have insights into the progress of development, this is possible on three levels:

如果管理层希望洞悉开发进度，则可以在三个层面上做到这一点：

• Use case diagrams or themes provide the long-term perspective for management. For 1 year, or even beyond. But: they are not suitable for specifying details.

  用例图或主题为管理提供了长远的眼光。 长达一年甚至更长的时间。 但是：它们不适合指定详细信息。

• Story maps form the basis for release planning. Stakeholders interested in the release create the story map with team members. (Due to new findings, the scope may change during development.)

  故事图构成了发布计划的基础。 对发布感兴趣的利益相关者与团队成员一起创建故事地图。 (由于新发现，范围可能会在开发过程中更改。)

• Those who want to have a deep insight and influence the details during development participate in Sprint Review and Backlog Refinement.

  那些希望在开发过程中有深刻见解并影响细节的人可以参加Sprint审查和Backlog提炼 。

Only at low altitude, we see the details. And the Product Backlog is basically like a shopping list. Would you write down what you want to buy in a year?

仅在低空时，我们才能看到详细信息。 而且产品待办列表基本上就像一个购物清单。 您会写下您想在一年内购买的东西吗？

Last, but not least, the death of epics heralds the dying of consumerism. If you want something, you have to agree with the team and work closely together.

最后但并非最不重要的是，史诗的死亡预示着消费主义的消亡。 如果您需要什么，则必须与团队达成一致并紧密合作。

验尸 (Post mortem)

In the discussion with colleagues, they pointed out that even after a dissolution of an epic, small stories can be added. That’s right, and for me it’s an acceptable solution. What is lost in this case, however, is the “Big Picture” that I have shown in the use case diagram.

在与同事的讨论中，他们指出，即使在解散史诗之后，也可以添加小故事。 是的，对我来说这是一个可以接受的解决方案。 但是，在这种情况下丢失的是我在用例图中显示的“大图”。

Ultimately, the suitability of a product for users determines its success. Not how it was made. This applies to all development practices, including epics.Maybe you have come up with a sensible way to deal with epics?

最终，产品对用户的适用性决定了它的成功。 不是怎么做的。 这适用于所有开发实践，包括史诗。也许您想出了一种处理史诗的明智方法？

Learn how to manage your Product Backlog effectively by visiting my online course. This article was first published on HOOD Blog in German.

访问我的在线课程，了解如何有效管理您的产品积压 。 这篇文章最初是用德语在HOOD Blog上发表的。

翻译自: https://www.freecodecamp.org/news/epics-are-dead-heres-what-we-should-do-instead-279bada1e644/

敏捷史诗故事是什么