完整的需求與精短獨立小故事，完整小故事的不斷秩代

使用者故事Invest原則

Invest描述:
I dependent(獨立的):一個使用者故事對於另一個使用者故事應該是獨立的（儘可能的）。故事之間的依賴性使得增加了計劃編制，確立有限級，故事估計這些工作非常困難。通常，可以通過組合使用者故事或者分割使用者故事來減少依賴性。

N egotiable(便於溝通的):一個使用者故事是便於溝通的。一個故事的卡片是包含故事詳情的簡短描述。這些詳情是通過討論階段來完成的。一張還有很多詳情的卡片實際上減少了和客戶的會談。

V aluable(有價值的):每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

E stimable(可估計的):開發者需要去估計一個使用者故事以便確定有限級並對故事進行規劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

S mall(短小):一個好的故事應該在工作量上短小，描述具有代表性，而且不超過2-3人周的工作量。超過這個範圍的使用者故事，將會在劃分範圍和估計時出現很多錯誤。

T estable(可測試的) :一個使用者故事是可測試的來用於確認完成，記住，我們不開發不能測試的故事。如果你不能測試那麼你永遠不知道你什麼時候是完成了。一個不可測試的使用者故事例子：軟體應該是易於使用的。

一個編寫良好的使用者故事是敏捷開發的基礎。它們應該相互獨立，詳情應該便於開發者和使用者進行溝通，應該對使用者有價值，應該對於開發者來說盡可能的清晰以便進行估計，應該短小，通過預定義測試用例的使用確保它是可以測試的。

禪道里面的需求和原型圖、需求設計文件的區別

傳統管理模式中，很多產品經理都在用原型圖軟體設計原型圖或者非常完整的需求設計文件。設計完之後，交給設計人員進行頁面設計，然後由開發人員合併程式碼。那麼原型圖和使用者故事之間的關係和區別是什麼呢？

• 和user story相比，原型圖或者需求設計文件是一個整體，可以給人巨集觀的把握。這是原型圖的優點。比較直觀。
• 它是一個整體，所以就沒有辦法進行分解。你不可能分解成，做頁面導航條，做頁面的中間部分等。
• 沒有分解，所以原型圖也就沒有辦法進行優先順序的排序。比如頁面部分，有的很重要，有的不重要。但在原型圖裡面是體現不出來優先順序的。
• 沒有分解，自然也就無法進行跟蹤。你沒有辦法得知原型圖完成了多少。
• 過於死板，給設計人員和開發人員留下的發揮的空間太少，最後演變成被動執行。
• 需求設計文件規定的比較細緻，會讓產品經理陷入太多的細節，對整體的把握會減弱。

雖然相比較於使用者故事而言，傳統的原型圖或者需求設計文件有一些不足，但在實際的開發過程中，二者可以相輔相成。禪道從1.2版本中，已經增加了文件庫管理。可以將原型圖作為設計文件，上傳到某一個產品相關的文件庫中，和使用者故事相互配合，是一個最好的方案了。