范围即标的，是一个迭代冲刺的目标。围绕冲刺目标，通常会有匹配的：时间窗口、前后端开发资源、测试资源、运维资源、业务资源，同时会有匹配的协同系统协同处理方案、应急处理方案。当然，背后依赖的还有整个产品roadmap，再往底层其实是商业和战略规划。
范围的控制不论从风险、时间、团队信心哪个角度来说都是很有必要的事情（这里不谈绝对，比如突发的bug，不修复就要挂了，那没的说绝对是重要且紧急且马上就得做）。
1、风险控制：一个想要插队的需求，如果要做，不仅是开发、测试资源日历的问题。同时需要评估和既有范围的耦合度，其本身的相关方系统、业务有哪些，明确出来需求的地图边界在哪里。前面是进行风险的识别、评估，同时必须准备风险的应对措施，如果因为插队需求问题导致的诸如需要紧急
修复、回滚等，对原迭代范围的应急方案是什么？最坏的结果，如果发生了之后，还需要去做的就是持续的关注监控，避免次生的业务和系统问题发生，比如：系统和业务不一致导致的无效数据。关于风险，因为团队内分工的不同，会存在不同岗位角色的信息差，这里最好要有开发、测试、产品、项目、业务协同进行上述风险的预判过程；
2、时间：世上不如意之事十之八九，项目管理、产品迭代又何尝不是如此。人员请假、线上问题、bug暴露、老板需求都会挤压既定的时间规划。尽管我们在做迭代评审后，项目成员都会自己评估绝对的工作量，标记自己的deadline。尽管每个人都或多或少预留了一些buff，但是通常结果是，开发的交付、测试交付基本都会达到整个范围的deadline。不能说是团队成员效率问题，或许是deadline的标的成为了大家心理的一种暗示。所以范围蔓延通常意味着时间的不可控概率大幅度上涨。
3、团队信心：一次冲刺对于每个成员来说都是整装待发重新出发的一段旅程。大家有清晰的里程碑、有清晰的目标，过程中不断的持续交付并按照节点推进，最终达成一次交付。这感觉一定程度是可以刺激人的慢性多巴胺的，让成员充满信心、并拥有成就感和责任感；无控制的范围蔓延，会打乱成员的节奏，引起团队信心的打击，团队信心就像nba2k里球员的自信值，对于投篮命中率具有牛皮的加成效果。
每个产品经理成长过程中一定遇到过，加法的过程，我们想把一些小不点搭顺风车。不乏遇到由于评估偏差导致连累正常的范围。搭顺风车其实是件小事，但是需要背后评估分析的却是一套严谨的方法体系。
