今天玩了一个很有意思的游戏，叫掷筛子游戏。

这个游戏是这么玩的：

1）PO会给每个组发5张纸的Prodcut Backlog，每张纸上有大概10个PB，上面有每个PB的描述，每个PB的左下角有一个数字，500/450/300/。。。25/20/10/5；PO让我们每个小组来估完成这个PB需要的effort。

Lesson Learned:在这个过程中，PB里有个打印错误，Two打印成Too了，我们team内部就自己修订了，但是，有个Team是和PO确认的，这一点做得很好，因为，发现了问题就是要和PO及时确认，因为你认为得不一定就是对的。

2）我们Team，拿到后，就开始按概率算每个PB需要的掷筛子次数。算得蛮辛苦得，时间快到的时候，还有5~6个没有算完，就毛估估了一下。后来，PO跑过来说我们估得方法复杂了。后来每个team展示自己的估算时间的时候，发现有的team是用相对估计估的，这是个很好的idea。每个Team估算下来，我们发现我们Team估算的次数最多。

Lesson Learned:这个时候是按照Team成员固有地知识在做估算，没有考虑筛子的个数，形状等因素，所以估出来的值和实际相差很大。

3）PO告诉我们每个PB左下角的数字代表价值，然后我们每个Sprint的Velocity是15，要产生500的价值，然后，让我们做Sprint Planing。我们就傻眼了，因为我们之前估计得次数太大，15次根本产生不了这么大的价值，最多也只有100的价值，还是需要18次掷筛子。所以，我们上报给PO的是，我们一个Sprint不能交付价值500的产品，最多只能100。

Lesson Learned:这个时候整个Team就很沮丧，因为，发现其他的Team是可以交付500的价值，而我们不行。

4) PO开始给每个Team分筛子，让我们开始第一个Sprint的工作，我们分到了3个筛子，二个是4个面的筛子，一个6个面的筛子，还有一个30个面的筛子。我们突然发现，这些筛子和我们原先设想的传统的6个面的筛子不一样。这就导致一些原来认为需要花很多次才能掷出的筛子数简单了很多，因为我们可以针对PB有针对性地选择合适地筛子，有的是掷三次筛子，我们是三个筛子一起掷的。这一轮下来我们有个400的价值产出。

Lesson Learned: 事先可以问清楚筛子的大小，形状，个数。

5）PO让我们做Retro。我们派了一名成员去优秀的Team取经，发现他们的筛子比我们多，然后我们就管PO有目的地要了更多的筛子。然后把PB按照价值排了个序，高附加值的排在前面。

Lesson Learned: 我们之前都是3个筛子一起掷，没有成功，再一起掷3个筛子，其实，如果第一次掷地时候，有一个或者两个满足条件，那一个或者2个就可以放着不动，接着掷另两个或者一个没有满足条件地筛子。这是具体实施地经验和改进，这个是可以在Retro的时候，从流程或者具体实施地角度，思考如何改进。

6）接下来，我们就按产生价值的高低来开发PB，第二个Sprint交付了1000价值，到后面越做越快，都停不下来。

Lesson Learned: 在我以为越来越快，停不下来，是一件好事情的时候，因为Team对工作越来越娴熟，交付地能力越来越强。却没有停下来思考此时整个Team的ROI。虽然，随着高价值的PB被交付之后，Team每个Sprint可交付的价值越来越小，到后来一个Sprint只能交付180的价值，而Team每个Sprint的成本却没有下降，还是将近500。这个时候，Team没有停下来，而是继续在做。其实，这部分的PB可以被砍掉，或者交由外包来做。

总结:

PB中不确定的Bug要及时与PO沟通、确认；

Sprint之前要让PO澄清所有的需求；

做的过程中，多思考改进提高之处，以及多向优秀的团队学习；

当做的PB产生的价值从一开始的上升到趋于平缓的时候，就要思考，接下来的PB还有没有继续做下去的价值。