用戶故事在軟件開發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式；為了規(guī)范用戶故事的表達(dá)，便于溝通；包含角色、活動(dòng)、價(jià)值三個(gè)要素。
概念這種東西我喜歡說(shuō)文解字的方式去理解和闡述；用戶故事=用戶+故事=人+故+事，那就是一個(gè)人因?yàn)槭裁丛蛞鍪裁词拢釤挸鰜?lái)三要素就是who、why、what。從需求角度描述就是一個(gè)用來(lái)確認(rèn)用戶和用戶需求的簡(jiǎn)短描述。
用戶故事在軟件開發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式。為了規(guī)范用戶故事的表達(dá)，便于溝通，用戶故事通常的表達(dá)格式為：作為一個(gè)<用戶角色>, 我想要<完成活動(dòng)>, 以便于<實(shí)現(xiàn)價(jià)值>。
一個(gè)完整的用戶故事包含三個(gè)要素：
用戶故事的描述信息以傳統(tǒng)的手寫方式寫在紙質(zhì)卡片上，所以Ron Jeffries(2001)對(duì)這三個(gè)方面稱為3C：卡片(Card)、對(duì)話(Conversation)和確認(rèn)(Confirmation)。
（1）卡片（Card）：用戶故事一般在小卡片上寫著故事的簡(jiǎn)短描述，規(guī)則和完成標(biāo)準(zhǔn)。
卡片的正面書寫故事的描述，格式為：作為一個(gè)<角色>, 我想要<完成活動(dòng)>, 以便于<實(shí)現(xiàn)價(jià)值>描述需求；卡片背面書寫完成用戶故事的規(guī)則和完成標(biāo)準(zhǔn)，格式為：Given…When…Then。
（2）交談（Conversation）：用戶故事背后的細(xì)節(jié)來(lái)源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通；確保各方對(duì)故事的理解正確。
（3）確認(rèn)（Confirmation）：通過(guò)驗(yàn)收測(cè)試確認(rèn)用戶故事被正確完成。
好的用戶故事除了格式規(guī)范，要素完整外，還應(yīng)該遵循INVEST原則：Idependent（獨(dú)立的）；Negotiable（可協(xié)商的）；Valuable（有價(jià)值的）；Estimatable（可評(píng)估）；Small（小的）；Testable（可測(cè)試的）。
要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事。用戶故事間保持獨(dú)立性不僅便于排列和調(diào)整優(yōu)先級(jí)，使得發(fā)布和迭代計(jì)劃更容易制定，便于獨(dú)立地理解、跟蹤、實(shí)現(xiàn)、測(cè)試以及頻繁交付，也使得用戶故事的大小估算所涉及的范圍更清晰，從而估算偏差更小。
一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個(gè)用戶故事只是對(duì)用戶故事的一個(gè)簡(jiǎn)短的描述，不包括太多的細(xì)節(jié)；具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶故事帶有了太多的細(xì)節(jié)，實(shí)際上限制了用戶、團(tuán)隊(duì)的想法和溝通。
每個(gè)故事必須對(duì)客戶具有價(jià)值（無(wú)論是用戶、購(gòu)買方還是公司內(nèi)部角色）。用戶故事對(duì)于最終的用戶是有價(jià)值的，因此應(yīng)該站在用戶的角度去編寫，描述的是一個(gè)一個(gè)的feature，而非一個(gè)一個(gè)的task。
這個(gè)特點(diǎn)促進(jìn)團(tuán)隊(duì)的開發(fā)和測(cè)試成員由傳統(tǒng)的指令式工作方式向自驅(qū)動(dòng)的價(jià)值導(dǎo)向工作方式轉(zhuǎn)變，使團(tuán)隊(duì)中的每個(gè)人知道自己每天做的工作價(jià)值。
計(jì)劃會(huì)議里面一個(gè)很重要的環(huán)節(jié)，那就是故事點(diǎn)的估計(jì)。實(shí)際上就是對(duì)要開發(fā)的User Story進(jìn)行一個(gè)粗量級(jí)的估算，以便于團(tuán)隊(duì)能夠知道這個(gè)user story的復(fù)雜度（工作量）。
重點(diǎn)放在當(dāng)前迭代里能否按照該用戶故事的接收條件和團(tuán)隊(duì)定義的DoD(完成標(biāo)準(zhǔn))來(lái)完成這個(gè)用戶故事，如果不能完成，給出理由，由PO來(lái)決定是否拆分或者重新設(shè)計(jì)用戶故事。
讓開發(fā)者難以估計(jì)故事的問(wèn)題來(lái)自：對(duì)于領(lǐng)域知識(shí)的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時(shí)需要把故事切分成小些的）。
一個(gè)好的故事在工作量上要盡量短小，最好不要超過(guò)10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代中能夠完成。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。
一個(gè)用戶故事要是可以測(cè)試的，以便于確認(rèn)它是可以完成的。如果一個(gè)用戶故事不能夠測(cè)試，那么你就無(wú)法知道它什么時(shí)候可以完成。一個(gè)不可測(cè)試的用戶故事例子：軟件應(yīng)該是易于使用的。
用戶故事在遵循了INVEST原則后，基本就是一個(gè)好的用戶故事了。再重點(diǎn)分析三個(gè)準(zhǔn)則，幫助在產(chǎn)出用戶故事時(shí)更好地符合原則。
三個(gè)準(zhǔn)則是：一個(gè)用戶、完整價(jià)值、不依賴。
只包含一個(gè)用戶，因?yàn)槎鄠€(gè)用戶常常有細(xì)微的差別。一般是典型的用戶，常常有共同的某類需求。
完整地交付一個(gè)客戶價(jià)值。一個(gè)完整的用戶故事意味著這個(gè)故事完成后，用戶可以達(dá)成一個(gè)明確的、有意義的目標(biāo)。
依賴性的三種常見(jiàn)類型是：重疊、順序和包含。
總體上來(lái)說(shuō)，故事之間功能點(diǎn)相互重疊是需要避免的；順序關(guān)系是現(xiàn)實(shí)存在，在多數(shù)情況下可以通過(guò)一些手段解決；包含關(guān)系對(duì)復(fù)雜系統(tǒng)是有幫助的，對(duì)排定發(fā)布和迭代計(jì)劃的影響需要注意。
（1）重疊依賴
重疊依賴是帶來(lái)最多困擾的依賴形式，特別是多個(gè)用戶故事包含多個(gè)不同的重疊部分時(shí)，很難找到一組用戶故事可以代表該最小可行產(chǎn)品的功能集合，該集合應(yīng)該包含且僅包含一次需要的功能。
解決方式：
（2）順序依賴
順序依賴是指要使某用戶故事完成，另外的一個(gè)或多個(gè)用戶故事必須在它之前完成。順序依賴通常是無(wú)害的，而且有一些方式可以減輕這種依賴。
從敏捷開發(fā)的角度，整個(gè)系統(tǒng)是從初始的最小可行產(chǎn)品逐步演化為強(qiáng)大的產(chǎn)品，后面的每一步是建立在前面的基礎(chǔ)之上的。
但從另外的角度，不必要的順序依賴使得排列和調(diào)整優(yōu)先級(jí)變的比較困難，進(jìn)而影響制定發(fā)布和迭代計(jì)劃，也使得用戶故事的大小估算更難以把握。
解決方式：
（3）包含依賴
包含依賴是指在組織用戶故事時(shí)使用有層級(jí)的管理，比如常見(jiàn)的特性－故事兩級(jí)管理，一個(gè)特性包含多個(gè)用戶故事，這樣就構(gòu)成了特性對(duì)其屬下故事的包含依賴。
解決方式：
