参加的人员需要有产品负责人(PO)，团队所有人，包括开发职能和测试职能。这里我故意淡化开发人员和测试人员的概念，因为scrum团队追求的是跨职能的组合，职能可以有分工，但职位没有分别。
一般需求梳理工作坊发生的时间是提前1~2个迭代(sprint)之前滚动式进行，目的是留出足够的时间来准备。越长的sprint就需要越早做准备。需求梳理活动占用整个sprint时间的5%~10%。
PO与团队代表可以随时沟通，而全体人员参加的工作坊则代价较高，但好处是每个成员都有机会了解整个团队的状况，有助于知识和经验的传播，及跨职能的培养。另外，每个人也都有机会面对面与PO互动和发挥创造性，结果是提高沟通效率并且集思广益。
准备：
选择大型会议室作为开放空间，将所有待梳理的用户故事写在报事贴或卡片，并有序地贴在墙上。相隔一定距离便于走动和讨论。另外准备一些活动挂图(Flip Chart)供团队写写画画辅助讨论。还可以将已做完的用户故事及其估算贴出来，作为估算的参考基准。
第一部分，集体讨论：
根据团队人数可以选择分成小组。PO简单介绍用户故事的内容（团队成员最好事先有所了解，以提高会议效率）。然后设定时间盒(Time-box)，各小组针对面前的用户故事墙讨论范围(Scope)定义明确的验收条件(Acceptance Criteria，简称AC)。每张报事贴或卡片上写一个AC。推荐使用Given-When-Then的形式，好处是辅助思考并且便于后续转化为自动化测试。明确的验收条件将作为PO在sprint
review时验收的非黑即白的标准，"When you play the game of scrum you done or you fail. There is no middle ground."
有任何疑问(Question)或假设(Assumption)随时与PO澄清；如果当场没有答案，则记录在Flip Chart上，指定负责人会后跟进。
对于AC特别多的用户故事，引导师可以建议将其分解为更小的用户故事。
注意，需求梳理更多关注在what层面，而非涉及how层面的具体技术任务。
时间盒到期后，停止讨论，对于非常不清楚的用户故事，引导师可以建议推迟到下次。
可选地，引导师考虑增加一些时间盒继续讨论。
可选地，让不同小组巡游到其他小组交换想法，同样需要时间盒。
第二部分，相对估算：
使用man-hour的缺点在于每个人的技能水平不同，因此估算很难达成一致，或变成领任务者的自娱自乐，极端的情况下会造成不信任。
相对估算是将任务工作量（包括风险和不确定性）与个人分离开，因为不论谁来做，任务之间的相对比例是不变的。
引导师首先让大家回顾一下已完成用户故事点的单位基准。
大家围成一圈，先由第一个人选出一个适中大小的故事，贴在中间位置。然后依次挑出一个（只能一个）故事，如果比已有故事小，就贴在左侧，如果比已有故事大，就贴在右侧，形成横轴从大到小的故事泳道。如果差不多大小就贴在并列在同一列。每人都轮过一次后，引导师再问问还有没人愿意移动。没有的话进入第二个循环。
将斐波那契数列卡片（引导师只提供1,2,3,5及∞）或用计划扑克®，仍然大家轮流移动数字，放在认为合适的故事列之上。
对于过大的故事，引导师会建议PO后续分拆、进一步澄清，或是调整优先级。
当所有人都没有意见后，统计总点数，并拍照留待后续整理到电子工具或Wiki。
