在Scrum中，存在积压修饰的过程，其中部分处理将史诗/大用户故事分解为更容易在单个冲刺中估计和消费的小故事。
在JIRA Agile中，我正在寻找一种适当的方式来反映整理过程，并且仍然有一个可管理的积压项目清单以及对故事估计的准确跟踪。
以下是我看到的问题示例：
我现在已经积压了6张要优先处理和管理的门票，而实际上我只需要优先考虑最小的用户故事。此外，我可能对大型用户故事进行了大量估算，然后通过估算子用户故事来细化估算值。 （即第3步可能有大量的用户故事估计为20分，但子故事可能总计为13 + 5 = 18）
我是否按照JIRA中的预期方式分割故事？
一旦我对故事进行细分，我是否应该删除较大用户故事的估计值，而只关注最小故事的估计值以防止重复计算？
（我一直在使用Structure插件，但它无法帮助我管理敏捷板中的积压优先级。）
答案 0 :(得分：2)
史诗的概念是a very large user story that requires breaking down。
在Scrum中，积压是一个及时完善的过程。我们从粗粒度的想法开始，随着我们越来越接近开始研究某些东西，我们将其用于更好和更好的形状。
很有可能用故事来做所有这些。但是，许多团队发现，积压项目的定义不如故事更有用。因此使用史诗。
作为一个例子，我几年前与之合作的一个团队被要求研究医学证据产品。他们意识到所需的工作分为4个广泛的领域（即真正的大故事）。有一个明确的优先次序，这意味着他们需要立即在其中一个领域工作，其他人可以在以后继续。
团队决定立即将第一个工作区域分解为正常大小的用户故事。他们将这些项目添加到待办事项中。
他们还希望跟踪其他3个工作领域，因此他们添加了史诗来代表他们。
该团队开始了第一个领域的工作，并取得了良好的进展。很明显，他们将能够在几个冲刺时间开始下一个史诗。产品负责人开始通过分解它来改进史诗。他们多次与团队会面，一些故事进一步细分为小故事。当团队距离史诗开始大约1-2周时，它的形状很好，并且包含了可以用于计划会议的故事。
此时史诗对团队并不感兴趣。他们有他们需要的详细故事。该团队使用了JIRA，他们确实发现在问题上看到史诗名称很有帮助，因为这有助于他们清楚地看到积压。
我的建议是：
你可能会发现你将史诗打破了故事，但仍然需要保留史诗，因为还有更多的工作要做。如果发生这种情况，则表明你的史诗太大了。我建议将一部史诗分解成不超过10个故事（即使这个很大）。
尽量避免出现真正属于工作类别的史诗，因此可以继续制作新故事。你可能想在JIRA中使用主题或标签来做这种事情。
答案 1 :(得分：-1)
Epic不应该被列为故事而非史诗应该充当所有故事的父母。故事本身只有一个是史诗而不是故事的父母。