《人月神话》中提到了软件工程中的Brooks法则：

向进度落后的项目中增加人手，只会使进度更加落后

Brooks法则并不是像数据公式一样有严谨的推理，而且也没有介绍一个解决进度落后、除了增加人手以外还有什么通用方法。

实际上，敏捷会议中有一个叫做Cycle time。Cycle time的初衷应该就是解决这个问题，找出估算和实际时间出入很大的卡，对着这些卡，实际时间花的比估算的多，原因是什么，有什么可以采取的action；花的时间比估算的少，是为什么，有什么可以分享的东西。

还有一个作用就是让团队知道产生估算有出入的具体细节，做这张卡的人可以做一个澄清，一方面可以寻求团队帮助，另一方面当事人吐槽一下，可能他也很委屈，大家都抱怨这个做慢了，却不晓得是因为我趟了好多坑，这些坑是之前没遇到的；或者是之前估卡的scope变大了。

没有银弹，许多事情都需要case by case地进行分析，而Cycle time就是提供这种流程的实践，帮助团队发现估算有出入问题的原因。一切敏捷流程都是为了尽早暴露问题、增加沟通和加速反馈。