有没有人成功使用灵活的冲刺长度？ [关闭]

Question

我知道最佳 sprint 长度会因情况/公司而异。话虽这么说，有没有人成功使用灵活的冲刺长度？另外，我想知道是否有人对短（1 周）与长冲刺有强烈的看法？

背景：我们目前使用 1 周的冲刺进行开发。我们的产品负责人似乎对此很满意；但是，为了灵活起见，我曾多次要求增加某些项目的 sprint 长度。在所有情况下，我们都坚持短冲刺。

Answer 1

像往常一样：这取决于。

我目前在一个冲刺周期在两到四个星期之间的组织中工作。我个人对此并不热衷，因为很难衡量速度，而且组织的其他成员也很难将他们的日程安排与开发团队相匹配。

另一方面，这确实意味着很少有故事会延续到下一个 sprint，我们可以更轻松地考虑缺席、意外错误等 - 这通常会导致 sprint 被彻底取消。

我参与过尝试一周冲刺的团队。在实践中，与 sprint 计划、测试计划、部署等相关的开销意味着我们最终需要大约两天的实际开发时间：因此很难完成大型战略工作。我相信团队现在使用看板工作，根本没有固定的 sprint 持续时间，因此更快乐。

Answer 2

我们确定每个项目的冲刺长度。如果我们正在运行一个将持续 3-4 周的小项目，运行为期一周的 sprint 在那里没有任何意义，我们会切换到几乎类似于看板的方法。

如果我们在 1 到 2 周内运行一个长期项目。然而，我们不做的是绝对灵活地设置 sprint 长度，这最终导致了我们的报告混乱。然而，我们所采用的是将 sprint 的长度加倍。不是为了完成零散的任务，而是为了完成两个 sprint 加载，而无需解释我们为什么要重新安排内容。我们仍然尽可能避免这种情况。