我们是一个由3名开发人员组成的小组，使用Scrum处理一个项目。
我们使用 6 小时/天/开发人员进行容量规划。 我的问题是 - 如果我们使用 2 周的 Sprint 并且一天中的大部分时间（5-6 小时）都在做 Sprint 计划，我们是否应该将这段时间视为迭代的一部分（即这就是为什么我们使用 6 小时/天来解释这样的事情）。
对我来说，这超出了容量规划的范围，因为 6 小时/天/开发只是为了考虑开发人员每天做正常事情的生产时间......
您应该根据故事进行容量规划。这周你能讲多少个故事？这样，您就不需要考虑计划，因为它不是一个故事。
如果你的故事大小如此不同，以至于你无法在不考虑的情况下进行明智的计划：
- 估计任意"点"中的故事（基本上是将它们一个与另一个相对）（好）
或
- 打破你的故事，让它们都变得同样小（更好）
无论哪种情况，您都无需考虑任何地方的规划。
刺计划时间不应计入冲刺迭代。但是冲刺计划应该在2-3小时内完成，而不是一整天完成。既然你说你的团队很小，只有3个人，那么理想情况下，冲刺计划应该在这段时间内完成。因此，一天中的其余时间仍可用于冲刺任务。
我尝试了一些不同的事情，但以下是最适合我的理想：
- 将开发工作视为"闭门造车"的成本：如果她从未被电子邮件、会议、电话、午餐、啤酒跑步等分心，需要多长时间。
- 为您的团队确定"闭门"成本与现实生活之间的比率。 在"闭门造车"（开发人员更容易估计）中进行规划，并使用历史记录来确定比率。 这也允许您尝试降低比例（免费苏打水/午餐送货，上午 10 点至下午 4 点之间的电子邮件过滤器等）。
- 将冲刺视为有一整天的时间来计划、稳定和审查。 因此，对于为期两周的冲刺，请使用第 1 天进行计划，使用 9 天进行稳定，使用 10 天进行回顾/回顾。
因此，如果您有 5 名开发人员每天工作 8 小时进行为期两周的冲刺，并且您发现您的闭门/开门比率为 1.5，那么您有 5.33 个关闭小时 * 5 个开发人员 * 7 天 = 186.6 小时您可以计划的工作。
如果你有一个强大的SCRUM大师（或其他流程领导者），并推动你的团队有一个完整的"完成"定义（即记录，测试，伙伴建立和集成测试），你不需要稳定日，但需要一些努力才能到达那里。
这种混合过程的好处是，您可以使用开放/封闭比率来了解每个开发人员的工作习惯（有些人是很好的估计器，比率为 1，有些人对所有事情都悲观，比率可能低于 1）。
不，您不应该将冲刺计划视为冲刺迭代的一部分。
在计算开发团队的能力时，不会考虑团队在冲刺 （sprint） 规划期间花费的时间，因为在此会议中花费的时间对故事的开发没有贡献。