如果你的团队始终有一些故事或所有故事没有达到“完成标准（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?