产品待办事项和任务是否应该在不同的迭代路径中？

Question

使用Scrum 2.1流程模板时，我注意到TFS中的Sprint Backlog查询返回了本次Sprint中的Product Backlog Items和Tasks列表，但是在我检查时，这个列表看起来相当稀疏。经过一番查询定义的探索后，我发现该查询先匹配子链接，并根据迭代筛选子级。这很重要，因为有几个任务没有被分配到迭代中，因此停留在待办事项列表中。

然而，这让我想到了——由于Sprint的主要关注点是Product Backlog Item，而PBI应该在单个Sprint中开始和结束，那么为什么Tasks会在不同的迭代中呢？这样做有什么理由吗？此外，Sprint Backlog查询以这种方式结构化的原因是什么呢？

- bwerks

Answer 1

这取决于您如何使用TFS来计划迭代。如果您打算使用TFS 2012敏捷规划的全部功能，则需要维护工作项迭代。Sprint Backlog查询（或任何其他查询）不会影响Scrum板功能，它由团队管理中的调度和区域设置控制（可在团队主页上找到）：

迭代取决于PBI的大小：如果一个PBI（包括其所有子任务）可以在单个sprint中完成，则应将迭代设置为sprint级别（例如：\Release 1\Sprint 4\）。

如果PBI足够大，需要跨越多个sprint才能完成，则将其迭代保持在发布级别（例如：\Release 1\），并将其子任务保持在sprint级别。

- KMoraz

Answer 2

当你到达Sprint的末尾时，已经完成实现和验收了3/4的PBI，而最后一个PBI有2/3的任务已经完全实现，你需要做出一些困难的决定。你会：

a) 尝试拆除最后一个PBI的代码吗？

b) 把整个Sprint称为失败并重新开始吗？

c) 将未完成的子任务移到下一个Sprint中吗？

这是支持选项（c）的内容。这可能不是Scrum.org建议的做法，但它支持这种情况。

- Andrew Clear

---

我们的意图是保持进程中PBIs的数量较少，并在分支中执行它们，这样当PBI没有按时完成时，我们基本上可以获得a)。PBI和剩余任务被退回到待办事项列表中重新安排，并重新评估剩余工作量。所以基本上，是A和C的结合，只不过PBI与之相伴，因此它们仍然在同一个迭代中。 - bwerks

Answer 3

如果你在冲刺结束时有一个可行的特性，剩余的工作应该被拆分成一个新的产品待办事项和与新PBI相关的任务。

如果不这样做，你最终会管理一堆部分完成的PBI，这很难跟踪，并且会影响你的报告。

我不确定如果不将剩余工作拆分为新的PBI，你如何有效地整理你的待办事项并进行sprint计划。

如果你经常遇到这种情况，请考虑将PBI分解为更小的工作块。请记住，当你将PBI提交到sprint时，理想的PBI大小应在3-5天（在我的规模上为3故事点）或更短的范围内。

这里有一篇很好的博客描述了大小：http://www.agileforall.com/2009/12/agile-antipattern-taking-on-large-stories/

讨论大小并提到3-5天的线程：何时从功能请求创建PBI以及在何处划分它们的界限？

- Brad J

---

如果PBI既可以交付又不完整，那么我可以看到这种情况下它是可行的；但是我们非常严格，只有满足所有验收标准的工作才能被推广，所以这对我们实际上并没有发生过。当我们无法完成时，我们不会推广未完成的工作，而是根据剩余的工作重新评估PBI，这有助于磨练我们的速度测量，因为A）我们没有得到上一个迭代中的工作积分，B）我们将根据我们仍需完成的工作在下一个迭代中分配工作量。 - bwerks

你能推荐故事点（PBIs）应该在3点或更少吗？我们团队通常使用更高的数字，虽然可能是有效的（所有的PBIs都是由同样的人使用相同的决策过程估算的），但为了防止增加其他有不同经验的人员时，最好让流程更加标准化。 - bwerks

我在回答中应该使用理想天数而不是故事点。你提出了一个很好的观点，即故事点评估比例是特定于进行估算的团队的。我回去相应地修改了我的回答。我用过的最好的建立持久比例的方法之一是想出一个相当于3-5天时间范围的示例故事，并以此为基础制定您的比例。这使得在计划热潮中容易推翻故事并将其与您估计的项目进行比较。 - Brad J