将用户故事拆分为较小用户故事的JIRA过程

Question

在Scrum中，有一个处理待办事项的过程，它部分地处理将epics/大用户故事分解为更小的故事，更容易在单个sprint中估计和使用。

在JIRA敏捷中，我正在寻找适当的方法来反映整理过程，并且仍然有一个可管理的待办项目列表和对故事的精确跟踪。

下面是我看到的问题的一个例子：

1. 史诗是以个人票的形式创作的。(门票总数: 1)
2. 那部史诗被分解成三个用户故事：(门票总数: 4)
3. 我们试图估计第一个用户故事，并意识到它太大，所以我们把这个用户故事分解成两个更小的用户故事(门票总数: 6)。

我现在有一个积压的6张票，需要优先处理和管理，而在现实中，我只需要把最小的用户故事放在一起。另外，我可能对一个大用户故事做了一个很大的估计，然后通过估计子用户故事来改进这些估计。(即步骤3可能有一个较大的用户故事估计值20点，但子故事总数可能达到13 +5= 18)

• 我是否按照JIRA的原意，用正确的方式来讲述故事？
• 我应该删除更大的用户故事的估计，并且只关注最小的故事的估计，以防止重复计算吗？
• 我如何管理最终成为史诗的用户故事(并且仍然将它们与更高层次的史诗联系在一起)？

(我一直在使用结构插件，但它无助于管理敏捷板中的待定优先级。)

Answer 1

史诗的概念是它是一个需要分解的非常大的用户故事。

在Scrum中，待办事项是一个及时细化的过程。我们从粗粒度的想法开始，当我们接近开始工作的时候，我们就会让它变得越来越好。

用故事来做这一切是很有可能的。然而，许多团队发现，有比故事更少定义的待办事项是有用的。因此，史诗的使用。

举个例子，几年前和我一起工作的一个团队被要求开发一种医学证据产品。他们意识到，所需的工作分为4大领域(即真正的大故事)。有一个明确的优先次序，这意味着他们需要立即在其中一个领域开展工作，其他领域可以在稍后跟进。

小组决定立即将第一个工作区域分解成正常大小的用户故事。他们将这些项目添加到待办事项中。

他们还想追踪其他三个领域的工作，所以他们增加了史诗来代表他们。

该小组开始了第一个领域的工作，并取得了良好的进展。很明显，他们将能够在几个短跑时间开始下一个史诗。产品负责人开始细化史诗，对其进行了一些分解。他们与小组见了几次面，有些故事被进一步细分为较小的故事。当这个团队离这部史诗开始还有1-2周的时候，它已经处于良好的状态，并包含了一些故事，这些故事可以被引入到计划会议中。

在这一点上，史诗对球队没有任何真正的兴趣。他们有他们需要的详细故事。团队使用JIRA，他们发现看到问题上的史诗名称是有帮助的，因为它帮助他们清楚地看到了待办事项。

我对你的建议是：

• 在JIRA中添加epics作为未来工作的位置持有者
• 当你接近研究它们的时候，把它们分解成故事。
• 一旦一部史诗被分解成故事，你就不用再担心它了。
• 如果一个故事被分解成较小的故事，删除原始故事。

你可能会发现你把史诗分解成故事，但仍然需要保留史诗，因为还有更多的工作要做。如果发生这种情况，这表明你的史诗太大了。我建议，一部史诗应该分解成不超过10个故事(即使是相当大)。

尽量避免史诗，这是真正的工作类别，因此可以继续制作新的故事。您可能需要在JIRA中使用主题或标签来处理这类事情。

Answer 2

史诗不应该被列为故事，而是史诗应该成为所有故事的家长。故事本身只有一个父母是史诗，而不是故事。