讲出符合开发团队味口的故事。
上一章说了敏捷开发团队的构成与迭代过程，本章重点说一下迭代第一天的计划会议。熟话说“好的开始就成功了一半”，一个迭代的计划会议做得好不好确实直接注定着迭代的成功与失败。迭代开始之前，PO肯定都已经提前准备好了本次迭代的所有故事，并且提前都发给了团队熟悉，后来我们一般都会在前一个迭代快要完成的时候开一个下个迭代的熟悉会议，组织大家一起熟悉下个迭代的故事，一开始并没有这么做，是在过去的多个迭代中，发现每个迭代计划会议都会拖得很长，有时候会开整整一天还没开完，需要晚上加班继续把故事讲完，任务安排好。在回顾会议的时候我们有总结为什么会这样？我们发现每个故事消耗的时间都特别的长，大家会提针对这个故事提很多的问题，PO会跟大家解释这个故事的需求，有时候PO也没有想到的地方大家就会讨论，这样深入下去，那么时间就这样消耗掉了。最后大家就会觉得迭代会议开得太累，肯定不是长久的法子。如果团队能在计划会议之前做一次提前的沟通，这样团队会提前把自己的想法告诉PO，PO也能提前想好抉择故事的业务。如此一来后来的迭代计划会议确实高效多了，还能够节约下来时间提前做一些功能设计。
PO为了把故事讲明白，肯定提前都把所有的故事都想过一遍，流程是通的，也不会存在相互矛盾。PO有一个自己的用户故事地图，然后把故事地图中的故事按优先级放入Product Backlog排好顺序，从Product Backlog 进入迭代的故事列表就是Sprint backlog。PO一定不能拿出自己都还没弄明白的史诗级的故事拿进Spring backlog给开发团队。
计划会议的流程是这样的，PO把故事列出来，可以在白板上贴卡片，我们直接用的leangoo，一个电子版的看板。然后PO会一个个讲解这些故事，讲完一个故事，SM就会让团队成员提问，如果没有问题就开始估点，估点用扑克牌。现在摆在PO面前最大的问题就是故事怎么讲？大家觉得讲故事可能很容易，其他没那么简单，为什么了，因为PO和开发团队很少是站在同一个频道上思考的，PO经常是跟市场、客户、老板打交道的，从他们那里获取到产品的需求，所以他讲得更多是这个功能的重要性，这个功能的价值，而开发人员是跟机器打交道更多的，他们更多的是站在技术层面如何来实现这个需求，所以PO如果讲的时候越偏向于实现方式上面，开发人员就更容易理解，才会觉得这个故事符合他们的味口。
我到目前为止还在纠结这个故事描述的方式和详细程度，我觉得这个胃口肯定是某个团队的胃口，不一定适合所有团队，只有团队之间形成一种默契，那么交流起来肯定是事半功倍的，所以PO写故事需求，一定不要拘泥与某一种形式，一定得多尝试多思考。
故事不要写太多的文字，写太多开发人员也很少会认真的去看，写太详细也不行，会让有些人产生依赖，也不自己思考。之前就有一个测试人员，一个小时就写了几十个测试用例，怎么可能这么厉害，后来一评审他的用例发现用例的内容都是成段成段从需求中拷贝过来的，一问他这段什么意思，根本还没来得及搞清楚。所以太详细就容易产生依赖，也浪费PO太多精力在文字工作上。太少了肯定也不行，之前就见到过别的团队，故事就是一句话，作为一个用户，我希望能有某某功能，以便于我某某方面会更好。这样的需求开发人员肯定看着都是木的，就算你口才再好也难以有条理的把这个需求讲出来，就算讲出来了，开发人员也不一定有条理的接收了，开发人员肯定觉得你至少有张图吧，对着图讲也好有个消化过程。所以我们一般故事中的需求会涉及到业务说明、业务流程图、界面草图、验收条件，所以了不多不少刚刚好。
一个完整的故事，首先在卡片上会对这个故事有一个整体的说明，比如“作为一个药剂师，我希望可以查询到待配药或已配药的记录，以便于我对指定患者进行配药或取消配药的操作”。这是一个标准格式，作为...我希望...以便于...，三个省略的地方，第一个说出了这个需求的提出者，第二个说出了他需要一个什么功能，第三个说出了为什么需要这个功能，它有什么价值。然后在卡片后面我们有一个链接地址，进一步来描述这个故事，这个链接里就包含了该有的业务说明、流程图、界面草图和验收条件。
故事举列：
US993 查询配药记录
1、故事
作为一个药剂师，我希望可以查询到待配药或已配药的记录，以便于我对指定患者进行配药或取消配药的操作
2、验收标准
1、功能要求：（1）系统支持按收费时间，配药窗口，患者就诊卡号、门诊流水号、发票号查询当前登录药房的待配药处方信息；（2）系统支持按配药时间，患者就诊卡号、门诊流水号、发票号、配药窗口查询当前登录药房的已配药处方信息；
2、录入约束：卡号、门诊流水号、发票三个检索条件在同一个文本输入框内录入；
3、交互要求：（1）如果系统参数设定的是自动或手动配发模式，而当前用户未指定当前工位对应的配药窗口时，系统会自动在右下角弹出提示，要求用户设定当前工位对应的配药窗口。（2）所有功能按钮上要求有小图标标示作用。
4、执行结果：（1）查询到的结果必须与界面设计的内容一致，与后台数据库中的归档信息一致；（2）查询到的结果集必须按配药窗口号，患者挂号序号、收费时间（配药时间）依次降序排列；
3、需求说明
1、待配药界面
2、已配药界面