我想实施 Scrum，但我无法决定 Sprint 的长度。Ken Schwaber 似乎将 30 天与事实上联系起来……但我无法想象等待 30 天而没有改变方向或重新确定优先级的可能性。
我们的项目使用瀑布方法通常只能持续 1-3 个月，而转向 Scrum 可能意味着更少的微调机会。
我在考虑 1 周的冲刺，但这似乎是 Scrum 微管理。
进行 2 周的 sprint 可能是理想的，但我想知道其他人是否能够成功实现这一点。有什么缺点？管理冲刺时间较短的团队是否需要更多的工作/更少的工作/相同的工作？
顺便说一句... 3 周的 sprint 对我来说似乎很奇怪，谁来做 3 周的 sprint？为什么不让它4周。;)
我曾在进行 1 周、2 周和 4 周冲刺的团队中工作过。这实际上取决于您的组织。我更喜欢 1 或 2 周的冲刺。我目前管理的团队正在进行 4 周的 sprint，因为我们正在协调 12 种不同产品的工作。我希望尽快将它们移至 2 周迭代。
定义长度的关键是“完成，完成”。对于某些团队来说，这意味着在生产中。对于其他人来说，这可能意味着由企业验证以使用内部版本满足他们的需求。我会先定义完成，完成，然后看看如何围绕它构建你的 sprint。理想情况下，所有故事都在 sprint 结束时完成——而且你不只是在做 Scrummerfall。
我喜欢两周。它在问题上强制设置合理的时间框，但让您以更快的速度看到结果。30天是永远的。对于像网站这样快速发展的产品来说，一周很容易成为正确的节奏。
我进行了 1、2、3 和 4 周的冲刺。1 周的 sprint 太短，无法完成团队承诺，2 周是理想的，当我尝试实施 3 或 4 周的 sprint 时，我们无法有效地利用 QA 团队。（QA第一周会有更多的空闲时间）
产品负责人应该总是有机会改变优先级和方向。SCRUM 的目的之一是接受变化，并通过查看负责按时交付的业务需求和开发团队来让产品所有者负责优先级。
因此，即使您有 3 周的 sprint，也并不意味着产品负责人必须等待 3 周才能发现（可能）会破坏 sprint 的东西。
在极少数情况下，您必须在中间停止冲刺并创建新的冲刺，因为新信息或新优先级。
我在考虑 1 周的冲刺，但这似乎是 Scrum 微管理。
是的，但这会让你做更多的 Scrum：你每周都会做一个 sprint 计划、一个迭代演示和一次回顾。缺点是开销，但是，与为期一个月的迭代相比，您花在计划、演示和“回顾”一周迭代上的时间更少。
迭代越短，团队学习流程的速度就越快。
现在，根据项目的类型，可能很难在一周的延迟内完成有价值的事情。
在我忘记之前，我不做三周迭代:o)
如果您进行四个星期的迭代，您还可以用估计相同时间的任务替换尚未开始的任务。
2 周（如果您是 MF 装备，则为 10 个标准工作日；如果您是 MS 装备，则为 12 个标准工作日）是半个月（一个月通常有大约 20 个工作日，给予或接受）。此外，周比日更模糊，但比月更模糊，因此它使以周为单位的度量单位更适合更敏捷（更多给予/接受）的开发项目。
然而，我最后一次做类似 scrum 的事情是在一个学校项目中，它并不是真正的 scrum。所以在一个 10 周的季度中是 7 天的周。我真的很喜欢这种情况下的 2 周块。我觉得我可以完成很多工作，但我们可以经常调整时间表和计划。
现在我们正在进行 30 天的冲刺，并完成了桩。30 天 sprint 对我们很有效的一个原因是，我们的计划和估算通常需要 2 天（收集并决定从积压工作中提取哪些高级任务，获取高级任务并分解它们，对分解后的任务进行估算）任务，然后分配它们）。我们还留出 2-3 天的时间进行错误修复和测试。
我们已经在那里工作了 5 天，所以进行 2 周的 sprint 只会给我们留下 5 天的研发时间。到目前为止，30 天对我们来说是一个很好的平衡。
Sprint 长度可能因项目而异，但在同一项目中应保持不变。最好的办法是尝试为您的团队找到最舒适的 sprint 长度，我已经使用 Scrum 两年了，现在我们解决了 20 个工作日的 sprint。
我的经验告诉我，在需要快速交付和相对简单的编程（CRUD 操作、简单的网格和表单等）的项目中，最好选择较短的 sprint，比如两周。对于复杂性较高的事物（例如框架），可能最好进行更长的冲刺，例如四个星期的冲刺。我目前的项目倾向于最后一个选项。
但重要的是选择适合团队和产品负责人的长度。