菜鳥Scrum敏捷實踐系列索引
菜鳥Scrum敏捷實踐系列（三）用戶故事的組織---功能架構的規划
一、用戶故事的狀態：
用戶故事推薦定義五種狀態，分別是“構思”、“已批准”、“開發中”、“已完成”、“已驗收”。
只有符合項目組規定的驗收標准，才能置為“已驗收”狀態。
二、用戶故事驗收標准
由團隊決定驗收標准。 該標准可包括：
•已完成所有任務（開發、測試和記錄）
•正在運行和通過所有驗收測試
•無開放缺陷
•產品負責人已驗收
•可交付予用戶
在每次迭代期間按此標准完成所有故事。
用戶故事驗收標准的錄入：
三、編寫用戶故事六原則-INVEST
一個好的用戶故事應該遵循INVEST原則
獨立性（Independent）
要盡可能的讓一個用戶故事獨立於其他的用戶故事。用戶故事之間的依賴使得制定計划，確定優先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。
可協商性（Negotiable）
一個用戶故事的內容要是可以協商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。
有價值（Valuable）
每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。
可以估算性（Estimable）
開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計划。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
短小（Small）
一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計划，工作量估算等方面的風險就會越大。
可測試性（Testable）
一個用戶故事要是可以測試的，以便於確認它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應該是易於使用的。