关于需求的讨论
最近在辅导敏捷团队和教授Scrum课程中，发现团队提出的很多的问题现象可以归结为迭代前需求梳理（Refinement/Grooming）讨论不充分所导致。
根据自己多年亲身实践的敏捷经验，如果在迭代的计划会议上，团队来不及做到澄清和一致理解需求，而是在迭代过程中再进行需求澄清，那么往往导致“迭代紧张、测试不充分、估算不准确、精神面貌不良”等表面现象。
因此，对需求的充分理解应该是迭代的入口条件，应该成为Definition of Done （也有同学喜欢称之DoR, 笔者认为DoR也是DoD的一部分） 的一部分，来确保迭代能够健康地开始。
然后，更深入的根源则是团队不了解如何进行一场高效充分的讨论。
敏捷是一种辅助实现交付价值的手段，不应该过于繁重。下面就根据@申导 早年在诺基亚西门子通信工作时所学到的一种简洁讨论法：Scope-Question-Assumption（简称SQA）讨论会。
参与角色
- Product Owner 产品负责人或业务需求方：负责讲解需求，回答关于需求细节与优先级的问题。
- Scrum Master 或引导者或主持人：负责设计讨论议程，计时、控制场面。
- 研发团队（包括BA、程序员、测试人员）：负责提问、评估技术风险、对需求给出建议、澄清细节、给PO提供方案选择、将需求分解为验收条件。
过程
- 找一间开阔的会议室或者讨论区，移除多余的桌椅，便于走动。在墙上事先贴好多张白板纸（大白纸、Flip Chart）。在大白纸上分别写上
Scope范围、Question疑问、Assumption假设。准备足够的报事贴和水性笔。 - 团队分为3-4人的小组，包含开发与测试。主持人不参与讨论，负责计时和引导过程。讲解需求的人作为自由人在各小组轮流走动。
- 由PO迅速讲解各个大需求，并根据业务价值做大概的排序（见下文的业务价值矩阵，也可以绘制成用户故事地图的方式。然后每组“抢”一些需求卡片，按照对需求的清晰度来分类。
- 按顺序针对一个用户故事或需求点进行讨论。在Scope范围纸上记录下要做或者不要做的需求内容，以及分解以后的验收条件。在Assumption假设纸上记录下目前方案基于的假设与依赖，这些可以是当前确定的共识，但将来有可能存在变化的风险。在Question疑问纸上记录下目前PO无法回答的疑问，在会后需要进一步澄清。
- 每15分钟，每个小组留下最熟悉和最不熟悉的各一个人，其余人按照顺时针移动到下一个小组去提问。每组留下的人负责给其他组移动过来的人讲解目前的讨论结果，解答问题，一起继续讨论。在这个“异花传粉”的过程中，不同人的不同想法会得到碰撞、激发、涌现，形成“杂交优势”，所有人能够“共同进化”。
- （可选）随后可以根据情况，决定是否进行任务分拆。除了最熟悉和最不熟悉的人，其他人自行决定加入哪组。花20分钟自行分解任务。分解后的粒度希望达到2天左右工作量的大小，并且能够开发、测试及演示，或称满足DoR。
- 主持人询问大家对结果是否满意，以及为什么不满意。
- 对于AC特别多的用户故事，引导师可以建议将其分解为更小的用户故事。注意，需求梳理更多关注在what层面，而非涉及how层面的具体技术任务。
- 任务拆分的清晰度同样可以用“乱麻、砖头、钻石”来分类。并采用动物体积、T-Shirt Size、相对故事点等方式进行估算。
- 时间盒到期后，停止讨论，对于非常不清楚的用户故事，引导师可以建议推迟到下次。
清晰度
- 乱麻：不知道在说什么
- 砖头：基本有轮廓了，但场景还没想全或看不出
- 钻石：需求100%清晰明了，能完整复述出来
业务价值
- 白开水：说不出来用途，根本是没人用的伪需求
- 糖水：能解决一些实际问题，但也有一部分是自嗨
- 灵芝汤：迫切需要，针对要害，生死攸关
相对估算2.0 (计划扑克®升级版)
- 引导师首先让大家回顾一下已完成用户故事点的单位基准。
- 大家围成一圈，先由第一个人选出一个适中大小的故事，贴在中间位置。然后依次挑出一个（只能一个）故事，如果比已有故事小，就贴在左侧，如果比已有故事大，就贴在右侧，形成横轴从大到小的故事泳道。如果差不多大小就贴在并列在同一列。每人都轮过一次后，引导师再问问还有没人愿意移动。没有的话进入第二个循环。
- 将斐波那契数列卡片（引导师只提供1,2,3,5及∞）或用计划扑克®，仍然大家轮流移动数字，放在认为合适的故事列之上。
- 对于过大的故事，引导师会建议PO后续分拆、进一步澄清，或是调整优先级。
- 当所有人都没有意见后，统计总点数，并拍照留待后续整理到电子工具或Wiki。
产出
- 验收条件(AC)，具备实例，最好能够转化为自动化测试。可以借助Given-When-Then的格式来编写。
- 其他辅助澄清需求的格式，包括流程图、顺序图等图表。
- 分解后的用户故事。
- 优先级重排之后的产品待办列表（Product Backlog）