因此，我有很多积压的功能，我们将要开始一个相当大的项目。我正在努力定义sprint的结构，并且对社区反馈很感兴趣。
我在想的是：
冲刺应该总是在星期二结束（以避免过多的周末压力）。
还要别的吗？显然，敏捷还比这更多。我想为团队提供一个简单的大纲，说明在开始该项目时我们将如何运作。
我会考虑尝试短于一个月的冲刺。
就我个人而言，我发现一两周的迭代在快速获得有效反馈方面更有效。它还可以防止任何可能导致迭代级别出现问题的问题，这些问题会逐渐增加到难以管理的级别。
即使是 30 天的 sprint——对于 sprint 审查来说，两天听起来大约是一天之久……而对于回顾来说，一天听起来太长了 0.5 天。我发现，如果您需要的远不止这些，那么在迭代过程中就会出现沟通问题——所以您可能需要将需要长时间的评论视为可能的危险信号。
当然，这只是我的经验 - 主要是使用小型（4-12 人）团队开发 Web 应用程序。你的经验可能会有所不同。
也就是说 - 我肯定会尝试更短的冲刺。就像集成构建一样——如果你更频繁地做，很多事情会变得更容易。