Scrum3355中5個活動有個非常重要的Sprint planning meeting喜命，迭代計劃會關系整個迭代團隊對Sprint目標以及迭代用戶故事的理解與承諾颖变。在迭代計劃會之前，Scrum團隊經常會忽略一個非常重要的活動即Product backlog refinement脉让，即迭代梳理會翼悴。
Scrum標準的5個活動中沒有迭代梳理會刁赦，Product backlog refinement往往放在計劃會里。但是對于剛開始轉型敏捷的團隊或者外部干系人（需求提出人）比較多以及技術性較強產品煮剧，建議需求梳理會與計劃會分開斥滤，第一可以避免需求梳理放在計劃會里，造成迭代計劃會時間過長勉盅，團隊開會疲勞佑颇；第二PO提前與外部干系人或者架構師梳理需求，確定一個技術上可實現(xiàn)并優(yōu)先級明確的Sprint backlog item（SBI）草娜，為迭代計劃會提供符合DOR的SBI挑胸。
DoR：Definition of Ready 的縮寫，直接翻譯為“就緒定義”宰闰。DoR是指一個需求能夠被團隊接受的標準茬贵，認為該需求已經準備就緒，并可以納入到迭代看板中的“To do”狀態(tài)移袍，是需求準入的標準解藻。DoR的價值，有效防止“低質量偽需求”流入研發(fā)側葡盗，同時加強了PO對需求梳理螟左，以及涉及多業(yè)務時需求依賴關系的明確。
舉個栗子：某一個產品需求DOR：
1.以用戶故事為維度、業(yè)務邏輯胶背、驗收標準清晰
2.有優(yōu)先級
3.如有依賴巷嚣，則第三方依賴需求實現(xiàn)時間明確
4.有業(yè)務期望上線時間，版本規(guī)劃
5.原型圖或者UI原型完整
梳理會前
PO根據市場價值從產品Product backlog選擇符合團隊速率的迭代用戶故事奄妨，可以提前梳理用戶故事的一些業(yè)務邏輯涂籽，便于梳理會上澄清。SM確定會議的時間和地點砸抛，一般建議早于迭代計劃會2天進行梳理會评雌，參會人員一般是PO，SA（系統(tǒng)架構師）直焙，產品負責人以及外部需求干系人景东。如果新的迭代里面有技術故事，建議提前讓架構師輸出技術方案奔誓，梳理會上與相關干系人評審技術方案斤吐，確定后納入迭代。
梳理會中
PO講解下個迭代要做的用戶故事厨喂、業(yè)務邏輯和PO理解的用戶故事優(yōu)先級和措，澄清后產品負責人以及相關提出需求干系人對PO梳理的業(yè)務邏輯評審討論，是否符合需求蜕煌，以及用戶故事優(yōu)先級是否正確派阱，如達成一致后，則架構師提前考慮用戶故事技術難度斜纪。如果迭代中有技術故事贫母，則架構師需把技術實現(xiàn)方案比如數據模型設計與相關干系人評審。會議最后輸出一個明確優(yōu)先級以及業(yè)務邏輯明確盒刚，技術可實現(xiàn)的SBI腺劣。
梳理會后
梳理會后，PO根據討論的結果整理Sprint backlog item因块，為迭代計劃會做好準備橘原。
產品項目中經常聽到PO反饋自己梳理了一個用戶故事，Scrum Team反饋技術實現(xiàn)難度大贮聂，需要2-3個迭代才能完成靠柑，導致PO對用戶或者市場的承諾變動，所以Product backlog refinement不僅能夠確定用戶故事優(yōu)先級吓懈、需求業(yè)務邏輯歼冰，也能提前識別技術實現(xiàn)難點，更有策略性的進行迭代計劃安排耻警。
