什么时候都不要延长迭代或 Sprint

Sprint 结束的前一天，某个重要的 story 出了问题，导致团队无法完成该 story。接下来该怎么做呢？把这个 story 放入到 backlog 中，还是延长 sprint 的期限？ Pablo Emanuel 说可以把 story 放回到 backlog 之中，极端情况下甚至可以取消 sprint。他继而说道延长 sprint 期限与迭代式软件开发的原则背道而驰：

迭代式开发的核心思想是尽可能频繁地反馈。你一不小心就会延期，尤其在初始阶段，但是，与体育锻炼类似，那些有私人教练及固定计划的人，与想来就来想走就走的人相比，他们在体育馆露面的机会要多得多，所以永远不要拖延。

除此之外，他指出迭代的演示非常重要，即使可演示的功能很小，它可以让大家有机会见面并回顾最近的迭代计划。

Maurice le Rutte 提示说：“承认发现了问题、任务无法完成会提高团队的可信度，乃至诚信。推迟演示则会发出完全不同的信号，即你们无法控制流程，将来都会拖延。”他继而提醒我们应该感谢团队，因为赶在客户之前就发现了问题，同时要使用回顾会议来发现故事到底出了什么问题。

Dan Rawsthorne 指出：举办审查和回顾，这可以让产品负责人重新评定下一个 sprint 中要完成的故事的优先级，可能把这个有问题的 story 排除在外。

如果团队总是定期出现这种情况，Scrum Master 应该相信是计划出现了问题。 Cenk Çivici 追问为什么 story 没有完成：“Story 是不是太大了？有没有明确的验收条件？是否测试花费了太多的时间？有没有足够的测试人员完成 story？”

Juan Banda 则提醒我们使用 INVEST 六原则：好的用户故事应该满足这样六个原则： Independent 、 Negotiable 、 Valuable 、 Estimatable 、 Small 和 Testable ，并怀疑 story 是否没有满足 Small 原则。

Inanc Gumus 解释说团队只有 3 个人（不包括产品负责人和 Scrum Master），他们初步估算 story 只花费 3 天。比如：“作为广告客户，如果我的活动经费用完了，我希望你们停止推送我的广告和活动”。团队认为这是他们所能分解的最小 story。

Paul Hudso 给出了更小的 story，这些小 story 可以合并成一个大的：“作为广告客户，我希望在任何时候都能让你们停止推送我的广告和活动。作为广告客户，我希望能在任何时候知道我已经花费了多少费用。”而 Ron Jeffries 采取了另一种方式：“第一个可以拆分出来的故事是：‘如果活动已经没有经费了，就停止推送’。这样就有两件事要做：包含一个 if 语句的业务逻辑；手工创建一个经费耗尽的活动。如果需要半天以上的时间才能完成，我想知道为什么。”

本文作者 Mark Levison 建议，Inanc 可以在回顾会议上问团队他们认为问题在哪里，可以使用根本原因分析以及其他的回顾工具。很可能他们已经知道了一些答案。

无论何种情况，最终达成的一致意见有：发现问题就马上提醒产品负责人；演示已经完成的功能；产品负责人可以重新排定优先级；使用回顾会议发现根本原因；不要延长 sprint。

参见原文： When to Extend an Iteration/Sprint