在MSF Scrum 2.2的积压中,PBI的承诺意味着什么？
bwe*_*rks 15 tfs scrum backlog tfs2012
试图了解我在TFS 2012 Web Access中的工作情况 积压| 产品Backlog,我使用"创建Backlog查询"按钮,然后在编辑中打开新查询以查看它是如何工作的.我注意到它显示了符合两种描述的PBI:
- PBI在新的/批准状态下的根迭代(积压)下的任何位置.
- 处于新建/已批准/已提交状态的待办事项(根迭代)中的PBI.
为什么PBI符合第二种描述？为什么PBI会在积压中承诺？是否可能是某种方式在完善后维护主题或史诗级别的PBI,并在用户故事级别的孩子致力于真正的冲刺时将其设置为承诺？它可能只是一种补偿劣质簿记的手段,其中不完整的PBI被踢到积压但没有将其状态恢复为已批准的状态？也许还有其他原因？
Bre*_*PST 72
新增 - 这些是有人添加到产品待办事项中的PBI,未经产品所有者审核且尚未同意构建.
已批准 - 这些是产品所有者同意,编辑并确保团队可以理解的PBI.一旦获得批准,他们就可以让团队参与sprint计划了.
承诺 - Scrum团队在sprint规划中讨论了PBI,创建了一些任务并同意在当前的sprint中构建PBI.
完成 - 在sprint审查中,产品所有者检查团队已完成的工作,如果他/她同意其符合要求和质量标准,则项目将移至完成.
- 好的,我会把它拼出来给你.您有一个产品待办事项,其中包含整个产品的要求列表.这些要求可能会分配给不同的团队.任何人都可以将产品待办事项添加到产品待办事项中.因此它是新的.如果PO喜欢这个想法,他/她可以批准它.在sprint计划时,团队将产品backlog项目放入sprint backlog中,并将其标记为Committed; 这是一个团队正在研究当前冲刺中的PBI.一旦PO满意,团队就已经交付了PBI,PO将其标记为已完成 (4认同)
你是对的!从一个SCRUM角度来看Committed,在积压中列出PBI 是没有意义的.该团队要么将PBI投入冲刺,要么已经没有.
有趣的是 - 在Sprint Planning或Sprint BacklogCommitted的SCRUM指南中没有提到这个术语.
我的猜测 - 微软使用这个术语Committed来描述开发团队从PBI转移Product Backlog到a 时的所有权Sprint,但不希望通过验证或自动更改PBI状态来强制执行规则.
如果您正在寻找更具权威性的来源 - MSDN上有状态图文章,其中描述了可用的状态点而没有进行裁判Sprints.
| 归档时间： |
|
| 查看次数： |
19316 次 |
| 最近记录： |