相对估算方法可能显得比较迂回，它不是敏捷团队可以采用的唯一方式。
理想开发者日(ideal developer days，IDD)估算故事，要求团队估计完成故事所需的总人天数，包括开发和测试。IDD这一概念比故事点更简单，而且它可以引起对故事点方法中一些问题的关注：
1、故事点方法不容易被团队理解，更不容易被外部涉众理解，这包括为团队提供项目管理辅助和财务治理的涉众；
2、故事点方法难以起步，除非团队已经完成若干迭代，否则将没有预计团队能够完成内容的线索。这一点在规划层面更棘手，因为在这个层面我们要合计团队估值，试图预测较大功能性在何 时可用。
3、进行进度和成本估算会非常曲折。你必须先进行相对估算、确定速率等。而且在把故事点转化为成本之前，还必须了解每支团队的负担成本。
4、团队要基于现有成员调整团队速率，有时候这会比较困难。例如，如果某成员只是在一个冲刺中兼职，或是某关键资源在一段时间内不可用，那么预期的速率是什么呢？
5、团队速率不是正规化的。一种并不罕见的情形是，某小型团队拥有每迭代40点的速率，而规模比他们大两倍的团队速率却只有其一半。这会引起一些比较不愉快的争论。
+
取而代之的是，采用IDD，使团队回到较为传统的工作估算方式。利用这种技术，团队查看每个故事，针对我们前面介绍的相同复杂性要素讨论故事，然后估计要用多少IDD完成该故事。这种估算法被称为“理想”开发者日的原因是，团队通常漠视他们在计划、演示、管理会议的能力，以及其它团队和公司的开销项。这种方法有许多优点：
1、团队一直是这样做的；
2、管理层总是需要进度和成本估值；
3、对它的解释理解简单很多；
4、针对病假、休假、培训等容易调整速率
然而，在我们急着把任何故事点团队重新培训到IDD之前，我们也必须指出它的一些严重缺点：
1、经过多次运用使团队倾向于被锁定。这种方式过于实际和意义丰富，团队感到必须把它做正确。而且，这种方式没有大相对数字的法则使每个故事平均到总计速率。
2、这种方式过于个人化并且有过多政治寓意。某开发人员可能说一个故事要用两天，另一人说四天。这对他们来说都可能是正确的，但是其结果是导致更多的有趣讨论，而且这种讨论不太可 能支持我们要努力争取的团队精神，因为这倾向于凸显新团队成员和其它有价值团队成员(他只是速度更慢)的较低速度。这就是现实，但并不是我们想要在每个冲刺中塞到人们面前的现实。更糟的是，如果这样的信息进入个人评价，那么你就有了大问题。
它是我们习惯的方式，但是天作证，那并不是特别有效。
