本篇用於給自己后續慢慢看，對敏捷感興趣的小伙伴，可以自行去看官方文檔或者各種網站的視頻講解，更詳細。
對於敏捷開發來說，User Story是開發的基礎，把原本需求拆成最小粒度的Story，以方便拆分Task，估計開發時間，領取開發任務。
一. INVEST原則
User Story可以遵循以下模板：As a <User Type> I want to <achieve goal> So that I can <get some value> 翻譯成中文就是：作為一個<某種類型的用戶>，我要<達成某些目的>，我這么做的原因是<開發的價值>。
Story 應該遵循 INVEST原則
- Independent 獨立性，避免與其他Story的依賴性。
- Negotiable 可談判性，Stories不必太過詳細，開發人員可以給出適當的建議。
- Valueable 有價值性， Story需要體現出對於用戶的價值
- Estimable 可估計性，Story應可以估計出Task的開發時間。
- Sized Right 合理的尺寸， Stories應該盡量小，並且使得團隊盡量在1個sprint(2 weeks)中完成。
- Testable 可測試性， User Story應該是可以測試的，最好有界面可以測試和自動化測試。每個任務都應有Junit Test.
user story: 代表一個 user feature。基於INVEST原則寫的story，應該是大家看懂的。如果哪個角色看不懂一個 story，那么大家會認為有可能這個 story本身有問題。我們可以讓PO去澄清一下，追加 comments補充或者修改一下 story的requirement的描述。一定要強調的是，user story一定是從用戶的角度來描述用戶渴望得到的功能。盡管 user story擁有模板，但是不提倡一個 story就一句話描述，驗收條件對一個 story來說至關重要。我們在jira或者confluence上面同樣還有 Epic的概念，Epic 翻譯成史詩，即非常大（巨大）的用戶故事。一個 Epic會拆分成多個 user story。
user story 的 3C原則：3C是收集用戶故事的有效手段，包括以下。
- 卡片（Card）：用戶故事一般在小卡片上寫着故事的簡短描述，工作量估算等。
- 交談（Conversation）：用戶故事背后的細節來源於和客戶或者產品負責人的交流溝通。
- 確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。
《敏捷估算與規划》書中介紹了兩種基本的方法： 理想人天法和故事點法。
相對來說理想人天法是在需求非常明確情況下，進行編碼和測試工作所花費的時間。問題是對於同一個項目不同的人根據其能力和經驗的不同，會有不同的理想人天。實際項目應用中，最好別用。
故事點法就是按照故事卡的規模和難度，給予每張故事卡一個點數。這也是實際項目中用到的比較多的。需要注意一點，1點數不等於1人天，點數代表的是難度系數。后續可以通過點數以一定比例整理成人天數，比例規則不同項目不同預算不同分析。