參加的人員需要有產品負責人(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。
