一、根据发布目标分析需求，把需求分析成独立的故事，初步的分析可以是粗略的，随着需求的不断深入刻意对故事进行整合或者切割。
要注意的是分析出来的需求尽量在发布目标的范围之内，超出发布目标的需求应该尽量避免过深分析。
所谓的发布目标是确定了这个版本可以让用户满意的条件。
故事模式：做为（用户角色），我可以（做什么），以便（业务价值）。后面的业务价值在比较简单或者大家都比较明确的时候刻意不需要注明。
当前团队实践推行方法：
第一阶段，这个分析工作开始由PM进行收集、整理和分析。
第二阶段，当大家都为用户故事的方式接受以后，采用需求讨论的方式来明确和分析用户故事。
二、对分析的故事进行相对估计，估计出来的故事点是对用户故事和复杂度的无单位估计值，使用的数值大小本身没有绝对意义，只有相对于其他故事规模的相对意义。
比如，用户登录这个用户故事的估计值是2，那么做为同等开发规模的用户推出，这个用户故事的估计只也应该是2。
当前团队实践推行方法：
第一阶段，这个估计的工作暂时由PM来负责完成，但是由于一个人的估计肯定会有偏差，所以在估计完成之后需要进行调查来进行修正。
第二阶段，用估计扑克会议来统一的对用户故事进行估计，当主持人拿出一个新的用户故事之后，大家给出自己对这个故事使用扑克打分，然后取出平均值，对差异较大的估计值要给出解释，来消除对用户故事的错误理解。估计扑克会议的实践不超过１个小时。
三、准备产品调查，对用户故事进行功能存在，和功能缺失性的产品调查，然后根据调查结果对用户故事进行划分，划分成3类：基本需求，线性需求，非线性需求。
此外还有反对的需求、存在疑问的需求、无所谓的需求3种类型的需求，这些需求将根据进一步的发展进行确认。
当前团队的实践推行办法：
第一阶段，由PM发出调查问卷在参与到项目的开发团队、测试团队、技术支持团队来进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性。
第二阶段，由PM发出调查问卷扩展到相关的用户群体中进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性。
四、确定发布规划，首先要确定的是迭代周期的长度，以周为单位，然后估计出每个迭代周期团队的速度。然后可以从用户故事池中选择出合适的用户故事来填充到第一次和第二次的迭代周期中。其余的暂时可以先不用填充，随着每次迭代周期的完成来对发布计划进行更新。最后根据估计的速度和需要开发的故事来确定需要几个迭代周期，并最终有几个迭代周期来确定需要开发的时间周期。发布计划可以以功能来驱动进行，也可以以日期来驱动进行。
发布规划的特点，以月做为时间范围，规划对象是用户故事，估计的单位是故事点。
文章来源于领测软件测试网 https://www.ltesting.net/