敏捷 Math
基于团队的敏捷的基本数学非常简单。您可以用几种方法对其进行切片，但最终，这三个基本公式之一必须成立。这都是关于时间，成本和范围的……您需要确定要锁定的两个约束，但是然后您必须导出第三个约束。
1.积压的大小/速度=持续时间
2.持续时间*速度=积压量
3.积压量/持续时间=速度
我通常建议敏捷性只不过是固定时间和成本，以及推导范围而已……但这不是必须的。随时根据固定的积压和已知的速度得出时间。您甚至可以根据固定的范围和时间得出计划速度。这是最危险的，因此请在计划展开时做好衡量，调整和谈判的准备。
限制在制品
但是这里有麻烦了……当一个团队有太多的工作要做，而没有足够的时间去做时，敏捷的信息和他们在地面上看到的信息之间就会出现认知上的不一致。我们可以整天说出采购订单可以决定“什么”，而团队可以决定“如何”和“多少”……但是，如果管理层固定了所有三个变量，团队就不会买账。
赶积压
通常，这是我向管理层提出的要求……给我们三个冲刺，以帮助团队提出未完成的订单并确定速度，然后我们将了解所拥有的东西并决定如何进一步进行。我们将首先进行足够的积压计划，以识别一两个冲刺的工作量，并让团队努力确定速度。
在团队开始确定速度时，PO积极移动以创建积压订单。我几乎从未看到可以自己创建积压的PO。通常，我们需要产品经理，架构师和分析师来绘制完整的图片。通常，我会请这些人全职工作，直到收集积压为止。
我有一个PO团队已经工作了8个星期，目的是要领先于团队并定义发布。最初，PO团队专注于为团队提供高价值，高风险的故事……但是随着积压的出现，我们开始对应用程序进行完善。如果一切顺利，经过数次冲刺，我们对构建的内容以及团队完成工作的速度有一个不错的想法。
到那时，我们应用三个公式之一，确定计划的基准，然后执行。
出现或收敛
您需要领先团队多大程度上取决于发布的业务目标。如果您不确定需要构建什么，则较小的待办事项可能会更好，并且发布计划过程可能更灵活。尝试预测您不知道的东西是浪费。在这种情况下，敏捷正在帮助支持紧急结果。
并非所有公司都希望获得紧急结果……有些公司想要稳定性和可预测性。在这些情况下，PO团队需要在团队之前进行进一步规划，并在产品开发时进行调整。我们越了解我们要去的地方，要到达那里要做什么，就可以对积压工作进行更深入的计划，就可以更加确定结果。在这里，敏捷支持集中化的结果，重点是降低风险和可预测性。
对于敏捷新手来说，我看到的最大问题之一是，当他们的产品需要一种紧急方法时，他们的行为就好像是在寻求稳定性和可预测性一样。要么对要求没有很好地理解，要么是由于技术风险高，或者由于如何实施尚有许多未知数。无论哪种方式，您都必须采取行动，好像项目已经出现一样，直到您获得足够的知识以建立更可预测的计划为止。
不知道你不知道什么
我最近遇到了几个团队，每个人都是新手，并不熟悉产品和代码库。您如何在这种环境中设置时间表？简短的答案是……您不知道。不知道可以，但是不永远知道也不可以。在这种情况下，您最好有一个计划来快速解决问题……无限期地要求企业投资而没有完成策略是不合理的。
