科恩的《敏捷估計與規劃》是一部敏捷估算方面難得的好書，系統的闡述了在敏捷項目環境中對進度的把控
估計方法：
P48 回報漸減法則
P50 斐波那契序列，工作量越大，估計的不確定性越高
P54 規劃撲克的價值不在於得到經得起未來所有審查的估計，而是花相當少的代價得到有價值的估計
重估
P64 計算速度時，要麼全有，要麼全無，我們感興趣的是小組的長期平均速度。但是，小組也可以選擇對部分完成的用戶故事進行重估。
在故事點和理想日之間做出選擇
故事點：
- 故事點是純粹的對功能的估計，能夠幫助促進小組的跨功能行爲。
- 用故事點估計比用理想日估計要快。
- 可以在小組之間對故事點進行比較。
理想日：
- 使用理想日有利於向開發小組之外的人進行解釋。
- 使用理想日更容易開始。
作者更傾向於使用故事點。
確定主題的優先級
新知識
目標不確定性可以通過獲取更多有關產品的知識來降低；方法不確定性可以通過獲取更多有關項目的知識來降低。
瀑布式開發和敏捷式開發對於消除不確定性的不同看法：
風險處理
風險和價值的4個象限：
對功能的正確開發順序：
這裏先處理高風險、高價值的功能的原因是，這些功能可以提供最高的價值，而對它們的處理可以消除顯著的風險。
10 確定經濟優先級
10.1 收入的來源
- 新收入
- 增量收入
- 留存收入
- 操作效率
10.2 例子：WebPayRoll
淨現金流
10.3 經濟指標
- 淨現值
- 內部收益率（Internal Rate of Return，IRR，有時也稱投資收益率，Return On Investment，ROI）
- 回收期
- 貼現回收期
11 確定合意性優先級
Kano模型，產品的3項功能：
- 閾值功能
- 線性功能
- 興奮點和驚喜點
11.1 用Kano模型評估主題
Kano建議通過問2個問題來確定一個功能的分類：
- 1：功能存在形式（functional form），有這項功能會覺得怎樣
- 2：功能缺失形式（dysfunctional form），沒有這項功能會覺得怎樣
將答案分類：
結果分佈：
11.2 相對權重：另一種方法
對收益和懲罰的估計使用1~9的尺度進行度量：
12 分割用戶故事
12.1 何時分割用戶故事
- 故事點太大。
- 雖然故事足夠小，可以放入單次迭代，但是本次迭代的時間不夠用。
- 對大型用戶故事進行分割有助於做出更準確的估計。
12.2 按照數據邊界分割
12.3 按照操作便捷分割
按照大型用戶故事中進行的操作對其進行分割
按照大型用戶故事的CRUD進行分割。
12.4 去除橫切考慮
12.5 不用滿足性能限制
12.6 分割具有混合優先級的用戶故事
12.7 不要把故事分割成任務
12.8 避免相關變化的誘惑
12.9 組合用戶故事
13 發佈規劃基礎
13.1 發佈計劃
確定滿意條件
估計用戶故事的規模
選擇迭代週期長度
估計速度
確定用戶故事優先級
選擇用戶故事和發佈日期
13.2 更新發布計劃
14 迭代規劃
14.1 迭代規劃是不分配任務
14.2 迭代規劃和發佈規劃的區別
14.3 速度驅動的迭代規劃
14.4 承諾驅動的迭代規劃
