How to write a product backlog step by step

一般来说，制定发布计划是在尝试回答这个问题：“最晚到什么时候为止，我们可以交付这个新系统的1.0版本“

下面是验收标准规则的一个例子：

1．  所有重要性》＝100的条目都必须在1.0版中发布。

2．  所有重要性在50－99之间的条目应该在1.0中发布，不过我们可以在紧接着的一个快速发布版中完成这些。

3．  重要性在25－49之间的条目也是需要的，但可以在1.1版本中发布。

4．  重要性《25的条目都是不确定的，也许永远不会用到。

下面是一个产品backlog的例子，根据上面的规则有不同标识。

   

重要性

名称

130

Banana

120

Apple

115

Orange

110

Guava

100

Pear

95

Raisin

80

Peanut

70

Donut

60

Onion

40

Grapefruit

35

Papaya

10

Blueberry

10

Peach

所以如果我们在最后期限之前能够发布从banana到onion的所有条目，我们就是安全的。如果时间不够用的话，也许我们可以跳过raisin,peanut,dount,onion。Onion以下的东西都算是额外的。

 

 

为了制定发布计划，产品负责人需要进行时间估算。如果时间估算最后被证明接近正确结果，那它就是有价值的；如果结果有所偏离，例如偏差了30％，价值则有所降低；如果它跟实际结果一点关系都没有，那就完全没用了。

时间估算结果的例子(以故事点表示)

重要性

名称

估算

130

Banana

12

120

Apple

9

115

Orange

20

110

Guava

8

100

Pear

20

95

Raisin

12

80

Peanut

10

70

Donut

8

60

Onion

10

40

Grapefruit

14

35

Papaya

4

10

Blueberry

 

10

Peach

 

 

 

估算每个sprint的平均生产率

投入程度表示“团队有多少时间可以放在当前所承诺的故事上“。它永远不可能是100％，因为团队会把时间用于完成未经计划的条目，切换环境，帮助其他团队，检查邮件，修复自己出问题的电脑，在厨房中讨论政治等等；

假设我们决定了团队的投入程度是50％（一把是70％左右），sprint长度是3个星期(15天),团队是6个人。

这样每个sprint都是90个人一天，但是只能完整交付45个人－天的故事，所以我们的估算生产率是45个故事点。如果每个故事的估算都是5天，那么团队在一个sprint中完成9个故事。

把产品backlog拆到多个sprint，如下表，

重要性

名称

估算

Sprint 1

130

Banana

12

120

Apple

9

115

Orange

20

Sprint 2

110

Guava

8

100

Pear

20

95

Raisin

12

Sprint 3

80

Peanut

10

70

Donut

8

60

Onion

10

40

Grapefruit

14

Sprint 4

 

 

35

Papaya

4

10

Blueberry

 

10

Peach

 

在不超过45这个估算生产率的前提下，我们把每个sprint都尽可能塞满了故事。

现在我们直到大约需要3个sprint来完成所有必须要的和应该要的。3个sprint大约是2个约。我们可以每隔3个星期就给客户演示一些有用的东西，并在过程中邀请他们改变需求。