讲故事的过程我们一般通过需求讨论会的形式来进行，确保以上应该参与的人员都到场。既然是个会议，我们就必须确保会议的高效，这里可以参考三星高效会议的8点原则：
（1）凡是会议，必有主题；
（2）凡是主题，必有议程；
（3）凡是议程，必有决议；
（4）凡是决议，必有跟踪；
（5）凡是追踪，必有结果；
（6）凡是结果，必有责任；
（7）凡是责任，必有奖罚；
（8）凡是奖罚，必须透明。
针对需求讨论会，我们至少需要有以下安排
- 会议主题：XXX产品需求讨论会，目的是在4小时内对XXX产品的XXX内容进行讨论
- 会议议程：
- 组织者：产品经理XXX或者项目经理XXX
- 参与者：业务方或最终用户，产品/项目经理，团队技术人员（架构，开发，测试等）
- 讨论内容（按照优先级排序的故事列表）
- 会议分工：
- 主持人：由产品经理和项目经理轮换组织
- 需求记录人：由技术团队内某人承担，负责在讨论过程中将用户故事和所产生的功能点进行详细记录，形成文档或者录入系统。
- 问题记录人：由技术团队内某人承担，负责在讨论过程中将无法现场确认的问题进行记录，形成文档或者录入管理系统。
- 会议交付物：
- 针对议程中的每个用户故事所产生的文档或者管理系统记录
- 讨论过程中所记录的问题列表或者管理系统记录
- 针对用户故事文档的下一步操作，如：制定开发计划，预算等等
- 针对问题的跟踪方式，如：问题列表的状态由谁负责维护，每个问题由谁负责解决跟进，每个问题预计解决的时间。
需求讨论会的过程就是按照以上3个步骤讨论故事和分析故事的过程，我们可以按照以下流程进行
- 讨论会前期准备
- 可以在进行正式的需求讨论会前先进行一次头脑风暴，邀请用户和技术一同参与，在这个过程中大家可以自由讨论。目的是让大家现对产品的大致情况有所了解。
- 讨论会过程
- 首先由主持人（产品经理PO/项目经理ScrumMaster）向团队列出会议所要讨论的故事列表，这个过程不用讨论细节，目的是让大家知道会议的内容和目标，便于控制进度。
- 根据所列出的故事列表优先级，从第1个故事开始梳理故事主线，分解功能点，并由专人负责记录
- 重复以上过程直到完成列表中所有故事的讨论
- 注意事项
- 一定要按照故事列表逐个讨论，每个讨论都要细化到功能点并完成记录，再进入下一个故事的讨论；不要先讨论所有故事主线，在一并分解功能点。这样做的目的是让团队可以聚焦，避免多条线索交织造成干扰。
- 在讨论每个故事的时候，不要讨论与当前主线无关的内容；特别是技术团队容易从一个功能点扩散到其他功能点，因为这是技术团队对产品的视角；这种扩散会降低效率。主持人在看到这种情况的时候应该适时制止，告诉团队其他的功能点可以留到其他故事中讨论，只要的产品的一部分，我们在后续的故事中肯定会涉及。
- 完成每个故事的讨论后可以进行短暂休息，在讨论过程中要确保每个参与成员都集中精力，避免形成小组讨论的形式。建议每个故事的讨论都站立在白板前进行。
- 主持人可以由PO和ScrumMaster按照故事进行轮换，主持人的主要职责是确保过程的顺畅，团队精力的集中。
- 待确认事项
- 建议在白板上开辟一片区域对讨论中出现的团队无法当场确认的问题进行记录，避免在这些问题上纠结太久，影响会议效率。