在敏捷迭代中，产品经理和团队需要对从用户、客户和其他干系人那里获得的需求进行梳理，以便程序开发人员进行开发活动。
上图是Scrum框架，在Scrum中，产品经理形成产品代办清单，团队成员自主选择该迭代承诺完成多少工作，即迭代计划会，当多团队时，可分为两部分，迭代计划会和迭代计划。
及时、高效与合理的需求梳理与迭代计划活动，是敏捷迭代健康、有序运作的关键！
需求梳理会
目的
第一，提前给团队成员讲解故事，讨论和澄清需求与设计疑问，预留时间解决问题，让正式迭代计划更高效、合理；第二，让团队成员了解产品全貌，而非仅关注自己的工作，促进成员间协作；第三，由团队成员来估算需求大小，量化团队容量，对估点内容达成一致，形成承诺。
需求梳理会一般是在迭代前3~4天，之所以提前，是为了在正式计划前，预留几天解决会上解答不清的问题，提前发现问题，在迭代开始前解决。 参与者有，PO、DM、Team全员参加，由PO主导。
活动
- PO依次讲解下迭代可能期望交付的故事，对故事依次及进行以下操作
- 团队思考故事要求和设计，提出疑问，PO或其他成员澄清疑问（可能包括对技术方案的疑问），直到没有显著影响工作量的问题
- 团队估点
最后需要输出产出物：1、更新的产品代办清单，调整故事；2、为解决的需求故事、方案问题，PO、DM记录会后解决；3、故事点数，记录到工具。
关键要点
会前
- 对较大的需求，一定要提前与业务、相关方沟通好方案设计，达成共识（方案未确定的需求不应进入需求梳理会和迭代计划）
- 对较大的需求，DDA或DM应提前输出概要设计，并评审通过
- PO提前准备好至少足够一个迭代交付量的故事，并写好AC
- PO应该和DM、核心技术骨干（2~3人）会前小范围碰一下故事准备情况，解决掉明显需求不明、故事太大、拆分不合理的问题，避免会上占用整个团队的太多时间
会中
- 全员参与，敏捷要求强团队协作，每个人理解整个产品全貌有利于长期的协作，不能只关心自己的任务；
- PO记录所有未完全解答的问题
- DM需要把控会议效率，对10分钟讨论不清的问题，让PO记下来会后再解决；
- 若讨论中发现故事太大或由遗漏需求，及时拆分和新增故事；
- 估点的要领参考下一页
会后
- 在正式迭代计划会前，确保所有未解决问题都得到解决
- 需求梳理会不一定依次搞完，不排除安排两次梳理会，每次更短的时间
用户故事估点
估点的意义
- 通过集体估点发现问题，让团队对需求的理解达成共识
- 每个人理解整个产品全貌，并理解其他角色成员的工作难度有利于长期的协作（敏捷宣言要点之一）
- 估算大小，可量化团队容量，利于未来制定合理计划
估点要点
- 估点活动的有效性取决于估点前PO和DM的准备工作
- 集体活动，点数包括前端、后端和测试总的工作量
- 工作量考虑三个因素：1、技术难度；2、改动量多少（如页面、接口、表等的新增和修改量）；3、可复用机会；
- 以总工作量1人天作为1点（故事点依情况而论，也可定义为理想工作日，或完成某个用户故事所用的难度），遵循左侧数列
- 不过都纠结，若相近就取大数；若三轮还无法接近，停止估点，PO或安排成员下去分析解决分歧；
- 估点按假设需要的准备条件都绝壁，专注投入做这个功能需要的工作量。
点数中不考虑以下时间：
- 多任务并行时中间的间隙、等待时间
- 预计用于修复缺陷的时间
- 外部接口依赖不具备导致的等待时间
- 团队间协作不畅可能的沟通耗时
