Scrum论坛

在现实生活中发生了什么，来确保a完成，完全集成，并立即可用的产品增量提供至少一次每个Sprint?

从你所说的，听起来好像大约200人，每个团队超过20人，计划推迟发布，直到5个假的“sprint”结束。如果是这样，那就不是吉拉的问题了。

谢谢你的回答。

在每个冲刺阶段，我们都计划进行一次内部发布。

在PI(5个sprint)结束时，我们计划发布正式版本，并将其交付给客户端。

不管怎样，这不是问题所在。我只是不知道如何处理发布，每个发布应该包含什么，因为一个

史诗可以持续5个冲刺

故事可以持续1个sprint

任务可以持续1个sprint

我倾向于同意伊恩的观点。如果你谈论的是将一个完整的史诗(就像所有相关的工作都已经完成)与一个版本联系起来，这似乎意味着你可能不经常发布或者你正在将大量的工作捆绑起来。这两种方法都不是有效的。如果你定期发布，你的故事和任务就是你的发布交付物，你的史诗是在更高抽象层次上可视化和跟踪的方法。这是我要考虑的第一件事——确保你的工作单元是小的、可发布的，并且可以定期和频繁地演示或使用。

第二个问题——将一个故事与多个史诗联系起来——是一个Jira问题。关于什么是史诗有很多定义，但在Jira中，史诗是工作的容器。即使一个作品可能支持多个史诗，Jira不允许为了跟踪和可视化的目的将一个问题链接到多个史诗。我的看法是，你可能想让你的史诗更小，更集中，这样工作就可以与一个史诗对齐，以支持跟踪和可视化。如果工作是切线相关的，您可以使用问题链接来关联它们，但它们不会在跟踪中显示。

你最好在Atlassian论坛上问这个问题。如何管理工作不是Scrum的问题。

在试图提供一些见解方面;版本应该只包含“已完成”的工作，对吗?所以如果你正确地连接了所有内容，那么如果一个故事有未完成的任务，那么它可能就无法完成，并且直到所有相关的故事都完成(或被淘汰)，史诗才会完成。

所以实际上，对于发行版本来说，唯一重要的是你称之为故事的东西。暂时忘掉它的管理，只问一下，什么是有价值的跟踪?

答案应该是我们能为客户提供的实际价值。任务不是价值。史诗只是一种价值分类的方式。故事可能是你应该优化的东西。

我就直说了。这不是本论坛的问题，原因有很多。

1.你没有使用Scrum框架。你似乎在尝试某种级别的规模化Scrum，听起来有点像规模化敏捷框架(SAFe)。

2.这是一个纯粹的JIRA问题，如前所述，在Atlassian论坛中会更好。Scrum框架没有提到用户功能、史诗、故事、任务、子任务或产品迭代(pi)。它也没有提到JIRA。

3.这是一个过程问题。Scrum框架不提供任何流程。这些都由组织来决定。

4.我们能给你的任何建议都只是我们的个人意见。但由于我们不在贵公司工作，我们的意见真的不重要。如果您的组织认为自己是敏捷的，他们就会知道每个决策都应该由最接近工作的个人做出。