在敏捷项目管理中，经常面临一个挑战：如何在产品待办事项列表中优先处理功能，同时确保业务需求得到满足。通常，会有一个详细的产品范围视图和开发人员对复杂性的估计。这里有大量的数据需要处理。
从纯粹的商业角度来看，最关键的变量是发布日期。日期对于公司内部和现有客户基础的推广有重大影响。以下是一些商业上的原因：
最重要的是，日期是完全非技术的。任何从小学毕业的人都能理解它。因此，发布日期有助于将讨论集中在重要的事情上，同时只需要涉及最少的技术细节。
假设范围不会改变，可以生成一个相当不错的日期预测。此外，可以模拟未来平均速率较高或较低对发布日期的影响。换句话说，如果需要一个计划，可以使用以下方法制作整个计划：
然后看看当改变速率时，每个版本的发布日期会发生什么变化。
已经定义、分解并估算了这个程序的范围。它包含数百个与交付大型基础设施相关的任务。所有这些都在使用一个名为Jira的标准敏捷工具进行跟踪，每个任务都有相关的细节。
作为中间步骤，需要进行以下分析：
如果提前估算每个任务的故事点，就可以在团队处理范围时观察速率。基本上，看到的是随着时间的推移，那个数字的变化。
在这个项目中，以每周的增量来跟踪速率。这为提供了更多的数据点，并比按月计算更快地提高了对数字的信心。更多的观察，更高的信心——从统计学上讲。
在上面的例子中，实际执行工作的团队每周交付27个故事点。但如果平均未来速率高于或低于这个数字呢？
对来说，获取真实数字的最快方法是查看报告。目前，所做的大部分建模都是基于Jira版本（fixVersion）。以前，使用不同的报告使用Jira史诗。
// 报告在左侧边栏
// 然后选择版本或史诗报告：
// 在下拉菜单中
// 最后，提取版本中实际完成的故事点：
// 以及不完整的：
// 最后，提取未估算故事的数量（计数），因为交付团队倾向于反对花费太多时间估算而不是工作：
// 记得排除已知的错误，因为这些通常有0个故事点，对于其他问题，使用判断。
将这些输入到Excel中（数据输入！）：
在电子表格中，为未估算的故事输入一个假设值，作为问题的平均大小（以故事点计），以及交付团队的预期速率：
基本上，一旦有了估计的总范围和速率，就只是将前者除以后者，以生成剩余的工作周数：
// 这里是用来生成神奇日期的实际Excel公式：
本质上，是在保持团队、范围和速率不变，并使用估计来计算每个版本何时准备好发布。这当然是基于现在所知道的，这是可能会改变的。
公式在版本中或多或少是相同的。在这种情况下，假设团队将完成版本1并立即开始处理版本2，所以列I需要一些调整。
首先，将光标移动到想要建模的变量上，在这种情况下是速率假设：
// 这是统计术语中的“独立”变量，想要变化它，以看看它如何影响关心的依赖变量：完成日期。
// 这可能是Excel最强大的非定量复活节彩蛋之一。虽然允许变化单个值，但可以推断出远远超出大多数人类直觉可能的影响。
// 在这里，选择场景管理器，然后出现以下内容：
// 点击
// 添加
// ，然后使用之前选择的单元格作为主要变量来变化：
// 可以将场景命名为对和公司有商业意义的任何名称。然后在下一个提示中输入这个场景的值：
// 然后再次为其他几个场景这样做。在这种情况下，创建了一个速率更高的60和一个速率更低的20。这个范围如此之宽，仅仅是因为没有数据可以参考，所以想探索乐观和悲观的场景。
// 当完成所有这些工作，场景管理器正确设置后，点击摘要：
// 根据这个，Excel会询问在变化场景时，实际上关心的电子表格中的哪些单元格（依赖变量）：
// 然后点击
// 确定
// ，Excel会挂起一会儿，然后返回以下神奇的表格：
这让对不同的平均速率如何影响交付日期和计划有一个感觉。通过查看边界，它也足以让对范围内的任何地方会发生什么有一个定性的感觉。这足以让拿去向利益相关者展示速率数字实际上意味着什么，可能需要调整什么权衡，可能需要增加什么资源，以及可能需要改变的其他所有事情，以影响速率。
当然，想要让它变得更漂亮，并澄清这些意味着什么：
好的，现在开始说话了！所以终于到达了速率手风琴状态。根据最终从团队获得的速率，这些是预计每个增量发布将达到的日期。正如所看到的，以20的速率完成整个范围与以60的速率完成整个范围之间的差异超过一整年。即使所有交付的细节完全相同，以完全相同的顺序，由完全相同的人完成，最终发布的差异也超过一整年。
换句话说，