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