敏捷开发中的团队管理、产品扩展与预测
1. 无需时间单位估算的发布计划
利用特定技术，我们可以创建带有日期的发布计划，而无需用周、天或小时等时间单位来估算产品待办事项。研究表明，人类在比较事物方面表现出色，例如比较建筑物的高度，但在使用米或英尺等单位估算建筑物高度时则表现不佳。通过利用这种比较能力并借鉴过往经验，能够提高估算的准确性，但请记住，这仍然只是估算，并非百分之百精确的科学方法。一项针对超过70,000个Scrum团队的研究发现，表现最差的团队是用小时进行估算的团队，其次是完全不进行估算的团队，而表现最佳的团队采用的是相对点数估算。由此可以得出结论：完全不进行估算比用天或小时估算要好。
在使用点数计算速度时，需要注意速度只是价值的一种间接体现，容易受到古德哈特定律的影响，即“当一个指标成为目标时，它就不再是一个好的指标”。速度应被视为一个与价值无关的指标，Scrum团队是其主要受众。团队应利用速度来关注发布计划，以便在过程中进行检查和调整。对于外部利益相关者（如管理层和客户）来说，点数本身并无实际意义。
2. 多团队管理的挑战与解决方案
假设拥有多个稳定的开发团队，每个团队都有既定的速度，那么所有团队在每个Sprint中交付的增量总和就是组织在该Sprint的交付能力。过去交付“完成”增量的历史是决定未来的主要因素，虽然可以计划或期望更高的速度，但速度自行提高的可能性极小。
组织常常试图让开发团队同时承担多个项目以获取更多产出，这会导致一种恶性循环。随着活跃项目数量的增加，对人员时间的竞争加剧，项目完成速度变慢，已完成项目数量减少。为了解决这个问题，组织往往会启动紧急项目，如“特遣部队”“老虎团队”或“阿尔法团队”。这些团队拥有
