本文转自：Leangoo敏捷工具
链接：文章源自玩技e族-https://www.playezu.com/189468.html
Scrum里不真实的二十件谣言之二：在Sprint当中是不可以更改Sprint Backlog的文章源自玩技e族-https://www.playezu.com/189468.html
很多人都说Developers承诺了交付在Sprint Backlog里的所有的内容，所以不可以增加减少或者修改任何Sprint Backlog，这样团队才有必要的专注力完成他们的承诺。文章源自玩技e族-https://www.playezu.com/189468.html
这是一个听上去多么有道理的说辞啊，但是它是正确的吗？文章源自玩技e族-https://www.playezu.com/189468.html
Scrum指南里是这么描述Sprint Backlog和Sprint Goal的： Sprint Backlog 是 Developers 为其制定的计划。它是 Developers 在 Sprint 期间为实现 Sprint Goal 而 计划完成的工作，是一个高度可视且实时的工作画面。因此，随着学到更多，Sprint Backlog 在整 个 Sprint 期间会进行更新。它应该有足够的细节，以便他们可以在 Daily Scrum 中检视其进展；Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺，但它为实现该目标所需 的确切工作方面提供了灵活性。当 Developers 在 Sprint 期 间工作时，他们将 Sprint Goal 铭记在心。文章源自玩技e族-https://www.playezu.com/189468.html
如果需要做的工作与预期的不同，他们将与 Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次 Sprint Backlog 的范围。显然这里说的很明确，Sprint Goal在一个Sprint里是固定不变的，但是Sprint Backlog不是。文章源自玩技e族-https://www.playezu.com/189468.html
这些恰恰迎合了Scrum的精髓-经验主义，我们很难准确的对未来的工作规划细节，即便是一个小小的Sprint。Developers 需要在工作过程中发现问题，找到障碍，了解变化，并启发下一步的工作。文章源自玩技e族-https://www.playezu.com/189468.html
比如说团队在工作发现一个技术插件可能不满足需求，需要找到替代者。或者为了完成Sprint Goal，我们发现有一个核心功能没有在Sprint Planning里讨论 等等。 大家想想如上的情况发生了难道我们不去调整吗？所以总之Sprint Backlog是灵活的，只要不影响Sprint Goal，我们允许其改变。文章源自玩技e族-https://www.playezu.com/189468.html
那么我们在什么时候去识别以及变更Sprint Backlog。答案是Daily Scrum，其给出了一个最佳机会每天去检查和适应，有必要的时候必须变更Sprint Backlog。
大家在工作中需要去建立拥抱变化的文化，鼓励团队去自管理的去发现问题，及时的适应。当变化是必须的时候去跟Product Owner聊一聊。这里再强调一遍，变更不能影响Sprint Goal。
最后我们探讨下Developers不承诺交付Sprint Backlog里的所有内容，那么他们应该再Sprint进行中承诺什么呢？
• 承诺完成Sprint Goal
• 交付一个可用的，高质量的，满足客户需求的Increment
• 时间精力花在价值高的内容上
• 承诺持续学习，改进
• 承诺在Scrum框架下，运用Scrum价值进行工作
总结
本文通过引用Scrum指南和举例着重介绍了如何击破谣言——在Sprint当中是不可以更改Sprint Backlog的。希望帮助到大家早日建立一个日趋完美的Scrum 团队。欢迎小伙伴们留言讨论。
本文作者：
丁志润：Derek Ding，Scrum中文网资深敏捷教练，企业敏捷转型专家，CSM，CSP（Scrum联盟认证Scrum专家）知识问答