关于产品backlog大扫除小贴士

如果我们没有给产品backlog大扫除以足够的重视,它就会变得比3年多都没修剪的灌木丛还要杂乱。今天这篇文章,我就跟大家分享一下PO在整理产品backlog列表时的4个小贴士。

小贴士1:

PO应该浏览整个backlog列表来找出要删除的部分。许多PO都有向backlog列表添加内容的习惯,但是却从不删掉那些不再需要的内容。如果一个特性不再需要了,它就应该被删除掉。

有些人会倾向于保留这些低优先级的内容,以便在未来什么时候再用上它们。如果你真的无法割舍它们,那么就想些法子把它们转移到其他地方吧。

假如你使用软件来管理产品backlog,软件中应该有删除功能。假如你用的是电子表格,那么把这些不需要的项从主表中剪切出来,粘贴到一个叫“长期产品backlog”的新表格中。我就是这样做的。而且,如果你像我一样的话,你把它们保存下来时感觉还挺不赖的,但它们基本上是不会再重见天日了。

小贴士2:

依然是关于避免产品backlog变大以至于失控的小贴士:为相关的待办项分组。我曾经碰到过一些PO试图管理超过2000项的列表。这也太多了。

我找到了一个合适的待办项的上限,就是在150到200之间。当一个产品backlog超过该上限时,它就会变得很难操作,基本上我们会很难理清各个待办项之间的关系;也很难记清是不是已经为某特性添加了待办项,于是又会加入一条新的,不知不觉间就加入了不少重复内容。

把相关代办项归到一组,称之为“主题”,这能让我们管理待办项时轻松不少。所以,我会把待办项进行分组。

小贴士3:

PO应该检查各个待办项的优先级。

代办项的优先级基于以下4个因素:

1. 特性的价值;
2. 实现该特性的学习成本;
3. 实现该特性将面对的风险;
4. 相对成本的变化。

小贴士4:

确认最高优先级的待办项能马上投入工作。每个最高优先级的待办项都应该被深思熟虑过,并能够在下一个sprint中投入工作,然后在正常情况下能够完成。

这并不是说每个待办项都要被完完全全地了解得非常透彻;而是说,一旦进行中的代办项出现了问题,团队和PO能在sprint中将其很快解决掉。

假如交付一个最高优先级的待办项需要召开3次“利益干系人指导委员会”,那么把它定位在最高优先级就是不明智的。

以上,就是产品backlog大扫除的4个小贴士。即使说它是大扫除,那也比车库大扫除要难得多啊。

 

原文作者: Mike Cohn

译者:Scrum中文网

原文出处:http://www.mountaingoatsoftware.com/blog/4-tips-for-spring-cleaning-your-product-backlog