作者 Mark Levison 译者 张晓庆 发布于 2009年10月14日 下午11时39分
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。
954
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
