我们目前有2周的冲刺迭代，我们将我们的PBI，任务和错误放在我们管理的主板上。
就Epics和Features而言，您为它们选择的迭代是什么，因为它们通常需要数月才能完成？
答案 0 :(得分：2)
<强> TL;博士; Epics and Features仅是一种组织结构，用于跟踪更大努力的进展。它们不应该被用于sprint / iteration。
这是敏捷中最混乱的概念之一，每次修复它的尝试似乎都会使情况变得更糟。了解这些术语的历史实际上可以真正帮助理解如何使用它们：
首先，我们有用户故事。当然，一些用户故事太大了，所以我们将它们分解成一组较小的故事。通常情况下，我们已将其分解，我们不再需要原始版本了。但有时候我们确实希望保留那个只是为了记住所有这些较小的那些，所以我们保持它，因为我们喜欢聪明，我们称它们为史诗，因为，你知道，史诗是一个大的故事。你可以在这里看到史诗不是一个有用的东西，它只是这些其他故事来自的占位符。
现在这些其他条款：有时甚至那些细分的故事都太大了，因为它是一个庞大的项目，需要分解。现在你有一个完整的史诗层次结构，这只是令人困惑，所以有些人仍然试图聪明地开始称他们为传奇或卷或传说。其他人认为我们变得过于聪明，并注意到PMI已经解决了这个问题，他们切换到传统的PMI术语，如项目组合项目，功能，子功能等。
没有标准。在构建像VersionOne或TFS这样的工具时，你必须把它们称之为东西，所以这些工具的制造者只选了一个（TFS选择了功能和史诗）。大多数团队都会选择他们采用的工具。
像我说的那样，我们制造了一个非常简单的概念。但是了解如何制造这些混乱有助于我们看到简单性并开始将它们视为占位符。