梳理产品待办列表一般会在产品待办列表梳理 （Product Backlog Refinement，也称Backlog Grooming）的会议上进行，这是一个反复发生、演变的事件，目的是不断地将产品愿景扩充成产品特性清单或PBI。通过举办定期的梳理会议为开发团队准备好在下一个Sprint要开发的PBI，同时为PO提供了一个解释列表中优先级高的PBI背后的战略目的的机会，这些对话有助于提高Scrum团队理解的一致性。同时定期的梳理会议也有助于确保需要实现的Story得到优先处理。一个产品待办列表梳理会议主要包括：
会议目标：定义愿景、发现待办事项、拆分大的条目、澄清待办事项。为开发团队进行更为准确的任务拆分和Sprint估算提供依据，为下一次迭代计划会的有效执行做好准备。我负责的两个团队backlog refinement的频率为一个spint 一次，所以每次做的都是对下个sprint的user story做准备。
会议参与者：PO，Scrum Master、开发团队成员和其他利益相关者。
会议准备、输入：PO负责和利益相关者负责梳理PBI，通常通过用户故事地图（Story Mapping）或者精益画布等工具产出Story列表。
会议流程：
1 po介绍下一个sprint 的sprint goal 并确保所有人都对其清晰 - 10 mins
2 根据po介绍的sprint goal，以及现有的prodcut backlog，来创建新的user Story，并且 确保每一个user Story达到团队定义的 “Definition of Done” ； - 40mins (这一步包括多个backlog的拆分和细化，以及确定Dod).
4 评估Story大小，并排优先级，为下一个sprint planning做准备。 - 10mins
会议输出：符合DEEP原则的更新后的产品待办列表，无论业务和技术团队都清晰地知道未来一个Sprint要做的PBI。
Deep原则如下：
