這是《落葉》文集里第 99 片落葉酬姆，希望你能喜歡嗜桌，不為別的，只為這份堅持辞色。
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.?
User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
什么叫用戶故事骨宠？就是從用戶的角度來描述用戶渴望得到的功能，英文叫做 User Story相满。
一個完整的用戶故事應(yīng)該包括以下三個要素：
角色层亿、活動、商業(yè)價值立美。
一個好的用戶故事應(yīng)該遵循INVEST原則匿又，包括以下六大特性：
INVEST?= Independent, Negotiable, Valuable, Estimable, Small, Testable
獨立性（Independent）：
要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事之間的依賴關(guān)系會使得制定計劃建蹄、確定優(yōu)先級和工作量估算都變得很困難碌更。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。
可協(xié)商性（Negotiable）：
一個用戶故事的內(nèi)容要是可以協(xié)商的洞慎，用戶故事不是合同针贬。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細(xì)節(jié)拢蛋。具體的細(xì)節(jié)在溝通階段產(chǎn)出桦他。一個用戶故事卡帶有了太多的細(xì)節(jié)，實際上限制了和用戶的溝通。
有價值（Valuable）：
每個故事必須對客戶具有價值（無論是用戶還是購買方）快压。一個讓用戶故事有價值的好方法是讓客戶來寫下它們圆仔。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進(jìn)行協(xié)商的時候，他們將非常樂意寫下故事蔫劣。
可估算性（Estimable）：
開發(fā)團(tuán)隊需要去估計一個用戶故事以便確定優(yōu)先級坪郭，工作量，安排計劃脉幢。但是讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通）歪沃，或者故事太大了（這時需要把故事切分成小些的）。
短邢铀伞（Small）：
一個好的故事在工作量上要盡量短小沪曙，最好不要超過10個人日的工作量,至少要確保的是在一個迭代或 Sprint 中能夠完成。用戶故事越大萎羔，在安排計劃液走，工作量估算等方面的風(fēng)險就會越大。
可測試性（Testable）：
一個用戶故事要是可以測試的贾陷，以便于確認(rèn)它是可以完成的缘眶。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成髓废。所以一個好的用戶故事巷懈，還需要定義 DoD（Definition of Done）。
其實不僅僅只有功能需求才能被轉(zhuǎn)化為 User Story慌洪，并加進(jìn) Product Backlog 里砸喻，很多相關(guān)的需求，都可以轉(zhuǎn)化為 User Story蒋譬，比如：代碼重構(gòu)割岛、架構(gòu)優(yōu)化、性能需求犯助、安全需求癣漆、上線需求等等。
很多 PO 在寫用戶故事或者在維護(hù) Product Backlog 的時候剂买，經(jīng)常會把 User Story 和Task 混淆起來惠爽，或者說 Scrum Master 和團(tuán)隊在溝通時，有時候也會分不太清 User Story 和 Task 到底有什么區(qū)別瞬哼？
我就基于我的經(jīng)驗和理解來闡述一下 What's the Difference Between a Story and a Task：
1婚肆、概念：
User Story 的定義是用戶想要得到什么樣的功能。
Task 的定義是描述功能怎么被實現(xiàn)坐慰。
2较性、承接對象：
User Story 因為包含的是一個完整的功能，所以承接對象一般來說就是開發(fā)和測試，也有可能會分為接口開發(fā)赞咙、后端開發(fā)责循、前端開發(fā)、UI 設(shè)計師和數(shù)據(jù)庫設(shè)計師等等攀操。
Task 因為指的就是一個單一的任務(wù)項了院仿，所以承接對象就是一個人。
3速和、顆粒度：
User Story 是通過若干個任務(wù)共同實現(xiàn)的歹垫，所以說它其實就是一個 Multiple Tasks 的集合。
4颠放、生命周期：
User Story：源于用戶排惨，載體就是 Product Backlog，貫穿于整個 Release 的始終慈迈。
Task：源于 User Story若贮，載體就是 Sprint Backlog省有，貫穿于每個 Sprint 里 User Story 的開始到結(jié)束痒留。
從這幾個維度上是不是能夠較為清楚地理解 User Story 和 Task 的區(qū)別了？
作者簡介：14 年測試 + 11 年項目管理 + 11 年團(tuán)隊管理 = 一個測試?yán)媳?/p>
