Sprint计划

不少研发团队的 Sprint 看起来很忙：计划会开了，任务也排进了迭代，站会每天照常进行，到了结束日却仍有三成需求没有完成，测试和上线还要继续顺延。问题往往不在团队不够努力，而在于…

不少团队把 Sprint 落地理解成“把需求切成两周一批”，结果迭代计划做得越来越满，延期却没有减少：开发说需求变了，测试说提测太晚，产品经理则在每次复盘时重新解释优先级。Spri…

Sprint 管理最容易失控的时刻，往往不是团队不会开计划会，而是计划会上承诺了 40 个工作日的任务，到了 Sprint 结束只交付了 25 个工作日的成果，剩下的工作又被原样搬…

不少团队把 Sprint 管理理解成“把需求排进两周，再开几次会”，结果迭代结束时，计划完成率看起来不错，用户却没拿到可用价值：测试被挤到最后，需求在中途不断插入，产品经理忙着催进…

很多团队的 Sprint 并不是输在开发速度上，而是输在“承诺的工作量”与“真正可交付的结果”之间：计划会上塞满需求，第二周临近结束时才发现测试排队、验收口径不一致、关键依赖还没确…

很多团队的 Sprint 并不是败在开发速度上，而是败在承诺的那一刻：计划会上把需求按理想工时排满，迭代中途又不断插入“只改一点”的事项，到了评审会，大家展示了不少完成的任务，却说…

迭代计划里写了 24 个需求，最后完成 15 个；团队加班赶上线，复盘时却把原因归结为“估时不准”，这是我在 Sprint 管理诊断中反复见到的误判。真正的问题往往不在某个人的估算…

迭代计划写得很满，Sprint Review 却总在解释“为什么没做完”，这通常不是团队执行力突然变差，而是计划把不确定性当成了确定工作。做好 Sprint 管理，不是把任务塞进两…

迭代管理如何做好Sprint？项目经理数据分析与操作步骤 Sprint 结束时，团队完成了计划故事点的 92%，但原定上线的功能仍有 3 项没通过验收，这类情况并不少见。它说明一个…

一个团队把迭代计划完成率从 62% 拉到 91%，上线延期却没有减少：延期项只是被集中移到了最后两天，测试缺陷和跨团队等待反而增加。这个反常结果说明，Sprint 落地的关键不是把…