使用者故事得到這麼多人的肯定，是因為它自身的優勢有很多：1、使用者故事強調口頭溝通，因為傳統的通過各種文件進行表達，每個人對於文字的含義的理解都不同，所以在閱讀文件的過程中可能會因為理解的不同對專案的完成造成影響；2、人人都可以理解使用者故事，並且使用者故事可以增強人們對各種事件的記憶；3、使用者故事的大小適合做發布規劃以及進行程式設計和測試；4、使用者故事適合於迭代開發，專案過程中可以寫出一部分故事然後就進行編碼和測試5、使用者故事鼓勵延遲細節；6、使用者故事支援隨機應變的開發，因為使用者故事注重口頭交流，而且很容易寫出或重寫出不同粒度的細節；7、使用者故事鼓勵有參與性設計，因為故事簡單易懂，能夠激發使用者的積極性使之成為軟體設計的參與者；8、使用者故事傳播隱性知識。
任何事情都有兩面性，所以使用者故事也有其不足之處：1、在大型專案中，故事間的關係會很複雜，所以要盡量保證使用者故事不要過於細節化，直到開發這些故事時才開始細化；2、如果開發過程規定要有需求的可追溯性，就需要有額外的文件，所以會花費一些額外的時間按激昂故事挪入或挪出來保持文件的更新；3、雖然故事能夠促進團隊內部隱性知識的基類，但是不適用於特大規模多團隊的結構，然後就需要將某些交流的資訊記錄下來，以保證團隊內資訊的充分共享。
使用者故事雖然較之其他需求方法更為簡單，但也不是很好把握它的標準。所以使用使用者故事時會有一些不良徵兆：1、症狀：經常需要調整估算，表現：故事太小；2、症狀：很難做迭代計畫，表現：故事相互依賴；3、症狀：開發人員子啊迭代過程中實現了計畫外的功能，或者僅僅憑藉自己的感覺實現故事，或實現的功能超出了實際需要，表現：開發人員實現了不需要的功能；4、症狀：花費太多時間去討論細節；5、症狀：過早考慮使用者介面細節；6、症狀：故事劃分太過頻繁；7、症狀：很難為故事安排優先順序；8、症狀：可不不願意寫使用者故事，也不願意為故事安排優先順序。
使用者故事在應用過程中還會遇到一些問題：1、處理非功能性需求：非功能性需求往往無法恰當地以故事形式來表達。非功能性需求型別如下：效能、準確性、可移植性、可重用性、可維護性、互操作性、可用性、易用性、安全性、容量。大多數的非功能性需求是約束，所以非功能性需求可以以約束卡的形式出現在專案中。2、紙質還是軟體? 紙質卡片和軟體各有各的好處，紙質卡片較為方便帶入各種會議，但是卡片的尺寸不利於寫測試用例，但是可以給故事描述文字乙個自然的上限，而且排序較簡單。軟體有利於不在同乙個地點團隊使用，而且客戶更傾向於用軟體而不是紙質卡片。所以在具體使用時要根據團隊情況具體選擇紙質或軟體來記錄故事。3、使用者故事和使用者介面：對於高度迭代的敏捷過程來說，傳統的使用者介面設計方法嚴重依賴於前期的設計，所以導致使用者介面實現後期或許會有很大的改動。所以產生了就產生了適用於敏捷流程的設計：1、使用者角色建模；2、捕撈高層次的使用者故事；3、排列故事優先順序；4、精煉高優先順序和中等優先順序的故事；5、對故事整理分組；6、建立書面的原型；7、精煉該原型；8、開始程式設計。3、是否保留故事：為了之後對產品的維護以及可重寫性和專案結束後一些文件的需求，保留故事更為有價值。
總而言之，使用者故事的優勢使其在眾多需求方法中脫穎而出，而其也有不足之處，這些不足之處需要一些額外的花費來彌補；使用者故事雖然簡單易懂，但是很好的使用它也不容易，所以要留意迭代過程中可能出現的各種症狀，然後對症下藥；還有就是使用者故事可能會與傳統的開發過程中的一些習慣有衝突，然後就需要人們根據其特性，適當做出改變。
使用者故事與敏捷開發方法筆記05
每一輪迭代完成之後需要開迭代計畫會議為下一輪的迭代計畫。迭代計畫會議包括 1 討論故事 2 從故事中分解出任務 3 開發人員承擔每個任務的職責 4 以上3項完成之後每個開發人員對其任務量估計，盡量保證自己領取的任務在下輪迭代結束時可以完成。討論故事 開發人員充分理解故事，在其中分解出任務 需要理清故...
使用者故事與敏捷開發方法筆記01
軟體需求是乙個軟體專案成功的關鍵因素，許多軟體專案失敗都是因為軟體需求的 不完整 不準確 不一致 而軟體需求是從業務需求經使用者需求最終得到系統需求的，所以業務需求是軟體需求的源頭，而業務需求又是從客戶業務中來的，客戶有問題且需要解決的業務才是業務需求。所以準確 完整的根據使用者的描述獲取使用者的業...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...