我: Tech Leader
团队：团队成员分布在两个城市，我所在的城市包括我有4个成员，另外一个城市包括SM有7个成员。另外由于我们的BA离职了，我暂代IT 的PO 职位.PM和我在一个城市，但他不参于敏捷的运作里面.
迭代: 双周
主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting.
现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3开始，外部教练基本上没有看我们的状况，由我指导着团队和远程的SM进行敏捷活动。
－－－－－－－－－－－－－－－－－－－－－－－－－以上是基本背景－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
不好意思，昨天晚上哄小朋友睡觉时，自己也睡着了，忘记上来写blog了。
Sprint Planning 是Sprint里很重要的一个会议，这个会议开得好坏，对整个Sprint的交付有很大的影响，开得好，团队可能会如期交付，开得不好，不但会影响团队的交付，而且还会对整个团队的气氛，士气有着消极的影响。
首先让我们一起来看看开计划会议的几个要素:
1. 计划会怎么开?计划会实际包括两部分，一部分是PO讲解需求(Grooming)，另一部分是团队估算并和SM排计划。
2. 什么时候开计划会议?上一个Sprint的结束或者Sprint的开始阶段。
3. 计划会的目的是什么？计划，定义Sprint目标和交流需求。
4. 开多久? 在一个双周的Sprint里面，我们的建议是2-4小时 (包括Grooming).
让我们来看一看如果计划会开得不好，会发生什么样的情况:
1. 估算不准, 会影响团队的交付承诺。
2. 对需求理解得不一致，会导致交付物不是PO想要的。
3. 需求不清晰，会导致开会时间都用在讨论需求了，开会时间会过长。
4. 团队承诺太少，影响产品的交付物或市场效应，一般很少发生这种情……
5. 团队承诺太多，导致团队交付不了，或者质量差，或者导致团队加班严重。
所以计划会的质量有时决定了Sprint的交付。
昨天星期二，根据团队的意愿，我们开计划会议，时间：下午四点到五点半，历时一个半小时。
输入：product backlog, 优先级
输出：sprint backlog, 估算
估算方法：以Sprint1的某一个2个点的story做为基准，
notes: 估算时将开发所需天数和复杂度一起考虑，留意，我们没有以开发的天数作为一个点数，而是以时间加复杂度的方式让团队一起分析并估算。
因为前一天开了grooming，所以在开会前我只是过了一遍backlog,好让大家有一个印象，然后我们再把原来定的基准Story拿出来，给大家回顾一下，就开始估算了。团队一起会将开发时间和点数联系起来，这个时候，SM就要强调我们的点数可能不精确，只是做为一个参照物和基准进行比较；并且要团队一起估算，我们就是让大家一起出手来投票点数，当某一两个同事的点数和大多数人不一致时，不一定是少数服从多数，而是让团队去发言，为什么要估这个点数，在这个讨价还价的过程当中，就会讨论需求，激发大家的思考和对需求的理解，这个时候呢，PO就最好是可以随时联系的，好让PO澄清需求，和回答和需求相关的问题。开始的几个story可能会花费时间长一点，因为团队还没开始进入状态，后来的估算进展还是比较顺利，大家估的点数都大体上一致。
估算完后，就是认领story了，我和SM坚持让团队自己认领story,一个人只可以领一个story,轮完一轮后再重新轮过，直到认领完为止，除各别的story要某个人才能做的需要指定，认领完后，基本就结束了。
总结：
1. 大家对需求的理解比以前加深了， 不像以前， 团队的个人基本只关注自己的任务，很少去关注其它人的任务。
2. 经过前两个sprint后，大家估算越来越准了，而且速度也快了。
3. 不足的地方是没有定sprint目标，这两天叫我们的SM定一下。
4. 由于上一个sprint还有些没完成，就没有在计划上定完成时间，完成时间我是今天才让大家更新上去的。
5. 明知有一些story是完不成的，该不该把它排进这个sprint了呢？教练曾经说过，就算完不成，也要排，否则在开早会的时候跟踪不了这个story的进度，因为早会我们是对着每一张story的卡片去过状态的。
6. 尽量完成这个sprint的所有story,不让它们遗留到下一个sprint去.
暂时写到这里吧，又两点钟了，睡觉去了，明天继续。