产品待办事项项目和任务是否有不同的迭代路径?

ehic 发布于 2019-03-09 scrum 最后更新 2019-03-09 14:33 3 浏览

使用Scrum 2.1流程模板,我注意到TFS中的Sprint Backlog查询返回sprint的产品待办事项项目和任务列表,但列表看起来相当稀疏,因为我查看了它。在查询定义中稍微查了一下之后,我意识到它首先在子链接上匹配,并根据迭代筛选子节点。这很重要,因为几个任务没有被分配一个迭代,因此正在积压。 然而,这让我想到了 - 因为冲刺的主要焦点在产品待办事项项目上,并且PBI旨在在单个冲刺期间启动并完成,那么为什么它对于任务是有意义的一个不同的迭代?有理由吗?同样,Sprint Backlog查询是否有这样的结构?

已邀请:

matque

赞同来自:

如果您在sprint结束时有一个可行的功能,剩下的工作应该分解为新的产品待办事项和与新PBI相关的任务。 如果你不这样做,你最终会管理一个部分完成的PBI的集合,这是一个很难跟踪并将丢弃你的报告的痛苦。 我不确定如何在不将剩余工作分成新的PBI的情况下有效地整理待办事项并进行sprint计划。 如果经常遇到这种情况,可以考虑将PBI分解为较小的工作块。请记住,理想的PBI大小是在3-5天(我的规模上为3个故事点)或更小的范围,直到您将PBI提交到冲刺。 这是一篇描述大小的好博客:http://www.agileforall.com/2009/12/agile-antipattern-taking-on-large-stories/ 讨论大小的线程包含3-5天的引用:When to create PBI's from a feature request and where to draw the line into splitting them up?

et_id

赞同来自:

当你到达Sprint结束时,3/4 PBI已经完成实施并被接受,而最终的PBI完成了2/3任务,你做出了一些艰难的决定。你做: a)试图撕掉最后一个PBI的代码? b)将整个Sprint称为失败并重新开始? c)将未完成的子元素任务移到下一个Sprint? 这是对选项(c)的支持。可能不是Scrum.org会推荐的,但这是它支持的场景。

id_aut

赞同来自:

这取决于你如何使用TFS计划你的冲刺。如果您打算使用TFS 2012 Agile Planning功能的完整范围,则需要维护工作项迭代。 Scrum Board功能不受Sprint Backlog查询(或任何其他查询)的影响,它由团队管理中的scheduling and areas settings控制(在团队的主页中可用):

Configure schedule and iterations... 迭代取决于PBI的大小:如果PBI(包括其所有子任务)可以适合单个sprint,则应将迭代设置为sprint(例如:\Release 1\Sprint 4\)。 如果PBI足够大以跨越多个sprint来完成,则将其迭代保持在发布级别(例如:\Release 1\)并将其子任务保持到sprint级别。