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个星期就给客户演示一些有用的东西，并在过程中邀请他们改变需求。