什么是用戶故事？
用戶故事（user story）是一個用來確認用戶和用戶需求的簡短描述，作為什么用戶，希望如何，這樣做的目的或者價值何在。用戶故事在軟件研發(fā)中又被描述為需求。用戶故事通常的格式為：作為一個<角色>, 我想要<功能>, 以便于<商業(yè)價值>。

因此，一個好的用戶故事就包括了這三個要素：
1.角色：使用者。
2.功能：需要完成什么樣的功能。
3.價值：為什么需要這個功能，這個功能帶來什么樣的價值。

另外，用戶故事還需要遵循3C原則：卡片（Card）、會話（Conversation）和確認（Confirmation），用戶故事的3C原則由Ron Jeffries在2001年提出，直到今天仍被奉為用戶故事的基本原則。

1.卡片：
用戶故事描述的傳統(tǒng)形式是手工書寫的用戶故事卡，卡片上應該只有幾句話來捕獲需求的精髓或目的。

后來產品經理們通過寫需求設計文檔或者規(guī)格說明書，通過一個非常完整的word文檔將某一個產品的需求定義出來。由于產品需求文檔涉及到的內容從項目到實現效果，非常龐大，以至于后來的項目管理中出現了摒棄繁雜的需求文檔的做法，或將需求文檔僅作為一個參考標準。如知名項目管理軟件 禪道提倡將需求文檔中的需求點摘出來，錄在禪道的【需求描述】里面，作為一個個獨立的功能點。
這其實跟卡片作用是一致的，用簡潔凝練的語言，完整呈現用戶故事的三要素。

2.會話：
會話指的是卡片上所記錄的用戶故事是可以進行討論和細化的，它包括利益相關人（客戶/用戶）、產品負責人及開發(fā)團隊之間進行更細化地討論用戶故事的可行性。用戶故事經過會話確認后，才能正式進入開發(fā)階段（用戶故事實現）。敏捷開發(fā)的流程完整體現了用戶故事（需求）的流轉過程。

以敏捷開發(fā)中的Scrum為例：

scrum的基本流程如上圖所示：
1.產品負責人負責整理user story，形成左側的product backlog。 ——用戶故事整理
2.發(fā)布計劃會議：product owner負責講解user story，對其進行估算和排序，發(fā)布計劃會議的產出就是制定出這一期迭代要完成的story列表，sprint backlog。 ——用戶故事確認
3.迭代計劃會議：項目團隊對每一個story進行任務分解，分解的標準是完成該story的所有任務，終每個任務都有明確的負責人，并完成工時的初估計。 ——用戶故事分解
4.每日例會：每天scrum master召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。 ——用戶故事實現
5.演示會議：迭代結束之后，召開演示會議，相關人員都受邀參加，團隊負責向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story。 ——用戶故事的二次整理

敏捷開發(fā)中用戶故事的細化為開發(fā)提供了可執(zhí)行標準，敏捷開發(fā)的特點是快速迭代，一個用戶故事的大小和復雜度應該在一個迭代中開發(fā)完畢為宜。如果用戶故事太大，可能會導致對它的開發(fā)橫跨幾個迭代。，此時就應該將這個用戶故事分解。每個任務的時間最好不要超過8小時，就是要保證1個工作日內完成，如果做計劃時發(fā)現有些任務的時間超過了8小時，就說明任務的劃分有問題，需要進行子任務的分解。

3.確認：
用戶故事確認可以理解為對用戶故事是否達到驗收標準的檢測。用戶故事需要一系列的驗收測試用以保證故事功能的完成及軟件按照我們的預期運行。同時要保證這個用戶故事最后實現是可以帶來商業(yè)價值的。

用戶故事的確認由測試人員完成。測試人員在測試版本所關聯(lián)的用例列表里執(zhí)行用例，完成測試，然后生成測試報告。測試報告是對用戶故事實現程度的最直接體現。

如果一個用例執(zhí)行失敗，可以直接由這個測試用例創(chuàng)建一個Bug，由開發(fā)人員進行二次開發(fā)和修復，直到測試通過。

寫好用戶故事除了要以3C原則為基礎，同時需要考慮到用戶故事需要具備的六個特征（也叫INVEST原則）：
Independent：獨立性
用戶故事之間應該具有獨立性，不應該依賴于其他的用戶故事。一般可以通過組合用戶故事或者分割用戶故事來減少用戶故事間的相互依賴性。
Negotiable：可協(xié)商
用戶故事是由客戶或者PO同開發(fā)小組的成員共同協(xié)商制定的，用戶故事代表了一個用戶群體的需求，而這個需求是零散的，通過相關人員的溝通，協(xié)商經常可以豐富用戶故事。
Valuable：有價值
用戶故事對于最終的用戶是有價值的，因此應該站在用戶的角度去編寫，描述的是一個一個的feature，而非一個一個的task。
Estimable：可評估
對于一個用戶故事的劃分需要足夠的領域知識，使得在劃分故事之時就能大致了解故事開發(fā)的周期，為了減少估算的不確定性，故事本身不能太大。
Small：短小
故事應該盡量的短小，當然也不是說越小越好。短小的故事可以減少分解過程中估算的誤差，最好的故事是能夠在一個迭代周期之內完成的。如果太大就應該考慮將其拆分為多個粒度更小的用戶故事。
Testable：可測試
如果一個用戶故事無法進行測試，那么也就無法判斷該故事是否真的完成。所以，用戶故事必須在定義了驗收測試通過的標準后才能認為用戶故事開發(fā)完畢。