如果你的团队始终有一些故事或所有故事没有达到“完成标准（DoD）”。他们应该延长sprint 时间吗？产品负责人应该如何处理这种情况？在这个特别的案例中，询问这个问题的人提到他们的团队以4 周为一个sprint。
Victor Hugo de Oliveira 指出，不应该延长 sprint。他解释道，sprint 是 Scrum 基本的时间箱，其目的是帮助团队集中精力：“时间结束时 Sprint 就结束”。 同时，他认为即便团队只能完成 90% 原先承诺在 sprint 中完成的故事，他们也应该集中精力去完成故事（比如，完成，完成）。
Jussi Mononen 说，一个 sprint 里没有完成的故事，由产品负责人自行决定是否移到下一个 sprint。 Angel Lopez 讲述了一个案例：
一个案例：在一个固定时间的项目中，我们“错误评估”了实现一个功能的成本。而且在下一个 sprint 开始的时候，产品负责人决定遗弃那个功能，对他而言，继续下一个故事更为重要。 对于当前这个故事，没有那个功能他也可以接受。
Adam Sroka ，教授团队在 sprint 中不要开始实现他们无法完成的故事，并且不要马上开始所有的故事，这样产品负责人可以有更大的灵活性在 sprint 里更改故事的优先级。
Jussi 也认为，这说明团队承诺过度了，一旦他们觉得无法在预期的 sprint 和发布中交付所有功能，他们就应该马上进行沟通。
Roy Morien 提出了两个观点：
- 2 周长的 sprint：“这是一个较短的时间范围，因此更加容易把计划的确定性做得更大些。尽管我没有统计数据来支持这这种观点，我认为这种更短的时间段让 sprint 更加可控，带来更少未完成的工作、更为准确的 sprint 估算、更强的紧迫感和承诺意识，总的来说，可以在团队环境中营造更好的心理和专注性。”
- 几乎完成、未经测试的故事代表了可能让项目受挫的组件，因为无法确定它们是否合适，也不知道它们隐藏了什么问题。
也有人问到，为什么团队不使用像 FitNess、RobotFramework 以及 Cucumber 之类的免费工具来编写他们的验收测试。
查看英文原文： Consistently Not Done, Done, Done at the End of Sprints?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论