在讨论PO如何给团队讲好故事这个问题之前，先给大家了解一些基本的敏捷概念，然后讲讲我们敏捷团队构成与整个敏捷开发的过程。
当初敏捷老师讲课的时候就跟我们所过，敏捷没有什么具体的形式，每个敏捷团队可能做法都不一样，表现出来的性格也不一样，比如有挑战型团队、有保守型团队等。但敏捷有一个核心是不能变的，这个核心就是3355。
1、3个角色：SM、PO、开发团队（自然包括了我们的开发人员和QA）。
2、3个产出物：Product Backlog、Sprint Backlog、交互的可用软件工件。
3、5个活动：计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理（发生在整个SCRUM周期的任何时间）。每一个会议都有自己的时间盒，其长短在SCRUM中都有比较明确的建议。当你召开某一个会议的时候，超出了这个时间盒或者召开某个会议的时候出现一些问题，也是一种有问题的信号。一个团队在冲刺的周期内，去充分的暴露问题，然后在回顾会上去分析问题，再进行改进。在每日立会上比较强调的是，根据昨天完成的情况来做出新的调整，我们每日立会上所描述的，一定是对有助于完成当前sprint目标的事情。同时，特别需要强调的是，在sprint评审会上，团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理，可以让团队有机会去回顾和识别版本发布的风险。
4、5个价值观：公开、专注、勇气、承诺、尊重。
另外，还讲到了SCRUM最重要的时间盒，这个是我之前所理解的SCRUM里面，没有发现它竟然是如此重要的。还学到一个新的理论：番茄工作法是一个人的SCRUM，SCRUM是一群人的番茄工作法；理解到跨职能是团队层面的概念，而一专多能是每个团队成员层面的概念。现在回过头来看，发现曾经团队在尝试SCRUM的过程中，对有些方面是理解得不够的，包括为什么最终团队放弃了SCRUM转向看板，其缘由也不完全是曾经以为的迭代周期的问题，需要系统的来看待这个问题。不管一套理论是如何的完善，结合到实际的工作中的时候总会遇到这样和那样的问题，但抓住最本质的东西才是最重要的，抓住其精髓的部分，然后再加以灵活应用，以问题为出发点，能够真正的解决实际的问题才能给大家带来信心。
我所在的团队有11个人，1个PO（也就是我自己），1个SM（他有兼职好几个团队的SM），6个开发和3个测试，这算是一个比较大的敏捷团队了，一般6,7个人一个团队刚刚好。然后我们团队开始开发一个系统，当然这个系统在分配到我们团队之前在公司是已经立过项的，有一个基本的PRD文档，架构设计也都已经确定下来（我们做应用系统的架构一般比较固定）。这时候我就会把所有的需求整成一个故事地图，然后根据故事的紧急程序会把故事放到对应的Product Backlog，然后请求开发团队对这些故事做一个简单的估算，好让我知道这些故事大概需要多少个迭代完成。迭代开始，PO拿出第一个迭代的故事给到团队，我们一个迭代是2个星期，10个工作日，一般第1个工作日开迭代计划，最后一个工作日做集成测试和迭代回顾，所以一个迭代真正做事的时间只有8个工作日。迭代第一天由产品经理给团队讲故事，然后团队对故事进行估点，这个一般都花费好几个小时，重点就是团队所有人都搞清楚这些故事有一些什么东西，再接着就是团队成员自由领用自己的故事，然后对自己的故事拆分任务排计划，这天最后团队一起给出一个本次迭代完成的信用值，信用值从1-5,5表示本次迭代肯定完成，4表示努力一把还是能够完成的，3表示可能加班才有可能完成，2表示加班都有可能完不能，1表示怎么搞都完不成。
一般开迭代计划会之前PO会把本次迭代的故事都会提前发给团队，让大家都提前熟悉一下故事，这样可以速缩短迭代计划会的时间。开完迭代会第二天不会马上就开始动手编码，一般上午会开设计评审和测试用例评审两个会议，开发人员设计的产出包含用例图、概要类图、数据库表结构和界面原型，设计评审就是对这些东西就行讨论。测试人员编写的测试用例，开发人员参与评审，就是验证测试理解的功能实现与开发想的是否一样，与PO想表达的是否一样。
评审之前开发人员可以准备一些资料，最好用图来表达自己的设计思路，不必编写一个什么设计文档来应付评审。接下来就可以进入编码实现阶段，每天早上准时开每日站会，大概10分钟，由SM组织，简要说明一下今天要做的任务，有什么困难加强团队的沟通协助。迭代过程中最重要的一张图就是燃尽图，基本上每个人都会关注，如果发现这张图下降得不正常，那么SM一般就会找出问题并进行干预。第一周周五的下午会组织一次代码走读，然后迭代完成的前一天会再进行一次代码走读。然后所有故事开发完成后，测试进入集成测试。集成测试完之后，测试会给出一个DI值，这个值的大小会决定本次迭代的成功或失败。然后开sprint评审会，由PO来验收本次迭代的成果。接下来就是最重要的迭代回顾会了，回顾会中全体成员总结本次迭代遇到的问题，以及解决方法，还有团队好的方面也要记录并保持下去，还会对之前迭代制定的解决方法进行回顾是否有用。
最后回顾会议中还会评出本次迭代的迭代之星，表扬表现最突出的成员，迭代之星最后会获得团队提供的一些小礼物。然后下周继续开始下一个迭代。
PO对产品负责，开发团队勇于对自己承诺的故事，SM是团队的保护伞。