Scrum Sprint: 冲刺长度：长度是多少？

两个长度指南

Sprint的长度有两个指导原则。

• Sprint启动后不应更改Sprint。
• Sprint应该是相同的长度。

我认为第一项目符号点是直截了当的。在Sprint开始后改变Sprint的长度会让人作弊。如果团队宽恕改变Sprint长度，那么就会有改变Story的Doneness协议以允许一些内部范围蔓延的诱惑。这是一件坏事 - 正确的做法是在Backlog中添加另一个故事。

至于Sprints的长度相同 - 这有点棘手。我已经建议启动Sprint只能持续一周，所以很明显我并不完全坚持所有Sprint应该是相同的长度。由于Sprint是一个反馈循环，团队需要考虑利益相关者。具有固定的Sprint长度使得利益相关者能够在产品评论中获得持续的“脉冲节拍”，这令人感到舒适并且引起了人们的熟悉。然而，对于专业冲刺而言具有不同的Sprint长度，例如适应假日季节，或团队和利益相关者可以达成一致的其他原因，对我来说似乎并不是一件非常糟糕的事情。

它足够长吗？

Sprint必须足够长才能真正完成故事。也就是说，团队需要能够完成故事。Sprint的规则是Sprint永远不会超过一个月。一般来说，Sprint长度大约应该是Swarm在平均中等规模故事上的长度的三倍并且完成它。这似乎在系统中提供了足够的“松软”，以允许团队自我组织以完成工作。我的经验是，对于一个典型的Swarming团队来说，一个故事大约需要2-3个日历日，所以合理的Sprint长度为两周。但是，环境不同; 有些人比其他人更容易（或更难）工作。我希望团队的Sprint长度根据环境的差异而有很大差异。

它足够短吗？

Sprint长度应足够短，以使需求流失速度低于Sprint长度所能容纳的速度。也就是说，如果Sprint长度是两周，那么团队希望需求的变化发生得比每两周慢一些。意思是，利益相关者可以等到Sprint结束时看到他们的“新东西”完成。

在当今的环境中，Sprint的需求流失速度通常太快。团队正在维护的其他系统中存在缺陷，整个组织都有紧急情况需要解决，利益相关者几乎不断改变他们对重要事项的看法。这些都是团队缩短Sprint长度或缩短计划周期的原因。

事情发生了，团队开发方法来管理需求需要比Sprint更频繁地更改的事实。

开放重新规划

有时团队的Sprint长度太长，他们的协议无法生存; 要求流失率高于Sprint长度可以承受的要求。制作更短的Sprint是很诱人的，但也许这样做是不可能的，因为利益相关者无法处理更频繁的评论，或者因为团队无法更快地开发产品。

Agile & Scrum Basis

• Comprehensive Scrum Guide
• What are Scrum's Three Pillars?
• What is Agile Software Development?
• Scrum in 3 Minutes
• What are the 5 Scrum Values?
• What is the Evolution of Scrum?
• Classical Project Management vs Agile Project Management
• Why is Scrum Difficult to Master?
• What is Velocity in Scrum?
• What is Agile? What is Scrum?
• What are the Three Amigos Development Strategy in Agile?
• Empirical Process Control vs Defined Process Control
• How to Maintain Transparency in Scrum?
• Scrum vs Waterfall vs Agile vs Lean vs Kanban
• What is 3355 in Scrum Framework?
• Why Scrum? How Does Scrum Overcome 8 Pain Points We Always face?
• The Best Free and Commercial Agile Tools - Every Scrum Team Needs!
• What are the 8 Wastes in Lean?
• Extreme Programming (XP) vs Scrum
• What is Timeboxing in Scrum?