00.有利于故事点的考虑因素
a.故事点有助于驱动跨功能的行为
b.故事点估计不会过期
c.故事点是纯粹对规模的度量
d.故事点估计通常更快
e.我的理想日不等于您的理想日
01.敏捷开发小组包含了来自于构建产品所需所有学科的成员，包括程序员、测试人员、产品经理、可用性设计师、分析员、数据库工程师等。
02.以故事点方式进行的估计比以理想日进行的估计具有更长的“保质期”。因为机组对技术、业务领域和他们自己的经验不同，以及其他的一些因素，都会导致以理想日进行的估计发生变化。
03.估计一件事需要多久时，重要的第一部是估计他的规模或者说需要做多少事情。故事点纯粹是对规模的估计，而理想日不是。理想日可以被用作对规模的度量，但是存在一些不足。
04.故事点对规模的纯粹度量带来了两个好处。首先，者意味着我们可以只通过类比就进行估计。有一些可靠的证据表明我们更善于估计“这个和那个差不多”而不是估计事物的绝对规模。另一方面，当我们采用理想日时，也可以用类比进行估计。但使用理想日进行估计时，我们也会趋向于考虑日程表以及用户故事需要多长的开发时间。
05.如果所有开发人员的水平大致相当或者程序员团总是结对工作(in pair)，就可以抵消生产率上的极端差异，忽略这个问题的做法就是可以接受的。
06.必要向外部人员（以及首先是对小组成员）解释采用功能点进行规模估计的概念。不过，您经常可以把对功能点做解释的有奥求当作对项目将要采取的总体估计和规划方法进行说明的机会。这是一个非常好的机会，可以让项目外部的利益相关者熟悉有关的想法，例如不确定性锥形、计划精度的渐进准确性、以及在一段时间内对速度的观察如何使您做出的计划具有更高的可靠性。
07.理想日的优势在于更容易想开发小组之外的人进行解释，以及更容易开始。我的倾向是使用故事点。使用故事点进行估计的有点更有说服力。如果小组对单纯的规模进行估计存在困难，我会让他们用理想日开始估计，然后在让他们转化到故事点上。我会更多地问“这个功能的规模与我们刚才估计的俺哥相比怎么样？”而不是“它会需要多少个理想日？”大部分小组几乎不会主义到这种逐渐的转变，而当他们意识到的时候，他们已经是在用故事点而不是理想日进行思考了。