00.有利於故事點的考慮因素

　　a.故事點有助於驅動跨功能的行為

　　b.故事點估計不會過期

　　c.故事點是純粹對規模的度量

　　d.故事點估計通常更快

　　e.我的理想日不等於您的理想日

01.敏捷開發小組包含了來自於構建產品所需所有學科的成員，包括程式設計師、測試人員、產品經理、可用性設計師、分析員、資料庫工程師等。

02.以故事點方式進行的估計比以理想日進行的估計具有更長的“保質期”。因為機組對技術、業務領域和他們自己的經驗不同，以及其他的一些因素，都會導致以理想日進行的估計發生變化。

03.估計一件事需要多久時，重要的第一部是估計他的規模或者說需要做多少事情。故事點純粹是對規模的估計，而理想日不是。理想日可以被用作對規模的度量，但是存在一些不足。

04.故事點對規模的純粹度量帶來了兩個好處。首先，者意味著我們可以只通過類比就進行估計。有一些可靠的證據表明我們更善於估計“這個和那個差不多”而不是估計事物的絕對規模。另一方面，當我們採用理想日時，也可以用類比進行估計。但使用理想日進行估計時，我們也會趨向於考慮日程表以及使用者故事需要多長的開發時間。

05.如果所有開發人員的水平大致相當或者程式設計師團總是結對工作(in pair)，就可以抵消生產率上的極端差異，忽略這個問題的做法就是可以接受的。

06.必要向外部人員（以及首先是對小組成員）解釋採用功能點進行規模估計的概念。不過，您經常可以把對功能點做解釋的有奧求當作對專案將要採取的總體估計和規劃方法進行說明的機會。這是一個非常好的機會，可以讓專案外部的利益相關者熟悉有關的想法，例如不確定性錐形、計劃精度的漸進準確性、以及在一段時間內對速度的觀察如何使您做出的計劃具有更高的可靠性。

07.理想日的優勢在於更容易想開發小組之外的人進行解釋，以及更容易開始。我的傾向是使用故事點。使用故事點進行估計的有點更有說服力。如果小組對單純的規模進行估計存在困難，我會讓他們用理想日開始估計，然後在讓他們轉化到故事點上。我會更多地問“這個功能的規模與我們剛才估計的俺哥相比怎麼樣？”而不是“它會需要多少個理想日？”大部分小組幾乎不會主義到這種逐漸的轉變，而當他們意識到的時候，他們已經是在用故事點而不是理想日進行思考了。