第一章：概覽
1.什么是用戶故事
作者在文中給出了如下的定義：描述對用戶、系統或軟件購買者有價值的功能。我們不難看出，對於用戶故事，他的立足點是用戶，那么他就是對用戶需求的描述。在BigMoneyJob網站的例子中：作者給出了幾個事例故事：（1）用戶可以搜索職位（2）公司可以發布新職位（3）用戶可以限制瀏覽其簡歷的人。不難總結，用戶，公司都是軟件的用戶。不理想的用戶故事則是（1）這個軟件將用C++語言來編寫（2）程序將通過連接池連接數據庫。如果是這樣，則變成了開發者故事了。用戶故事就是對用戶有價值的需求。
2.細節在哪里
如何編寫一個故事，像這樣嗎？（1）用戶可以搜索職位（2）公司可以發布職位，顯然這些需求比較龐大，甚至可以說沒有用處，它沒有細節之處，我們需要不斷地分解故事，知道有一個故事能夠覆蓋到每一個細節，簡單的一句“用戶可以搜索職位”，我們首先需要分解為（1）用戶可以通過地區，薪水范圍，職位，公司名和發布日期之類的屬性來進行搜索（2）用戶可以查看搜索結果中每個工作的具體信息（3）用戶可以查看發布工作的公司的信息。僅僅在第二點中，我們又可以繼續划分（1）查看工作描述（2）查看薪水范圍（3）查看工作地點，當然，這些不可能由開發者一人完成，需要與客戶不斷地交流討論，畢竟他們才是真正的使用者。
3.必須多長時間完成？
顯然我們需要知道用戶對於軟件完成時間的期望，這樣有利於我們對軟件完成的進度。
4.客戶團隊
這個類似於測試環節，但是又高於測試，建立一個客戶團隊，幫助開發者理解和完成所有的用戶需求，這其中離不開測試人員，產品經理，實際用戶和交互設計師。
5.使用故事的過程是怎么樣的？
客戶和用戶不應該只在開始的時候參與進來寫需求，而是在項目整個過程中全程參與。客戶團隊在迭代期間高度參與，與開發人員談論正在開發的需求，不過我認為，這樣做是否會有一個弊端，就是客戶團隊對於需求是否能夠一直不改變，是否會一直變動需求？
6.規划發布和迭代
為發布中的所有迭代分配好需求之后，發布計划便“浮出水面”，開發人員需要估算出他們在議論迭代中能夠完成多少個需求，客戶團隊則需要將這些需求按照優先級來分配到每輪迭代中。
7.什么是驗收測試？
驗收測試用來驗證實現的用戶需求是否符合客戶團隊的期望，而驗收測試嚴需要盡早的編寫並進行測試。
8.為什么要變？
需求集可以迭代，恰恰說明了需要，我們不必假裝可以實現知道並寫下所有東西，一客戶團隊和開發人員的討論為基礎，不斷地今年我們的需求。