1.需求分析的演變

　　在需求分析方面，敏捷ACP相對于傳統PMP項目管理有其顯著的改變，從冗長的需求文件演變成短小精悍的用戶故事。用戶故事的目的是以更快的速度、更少的消耗應對現實世界需求的快速變化。用戶故事的描述只要足夠（Enough）就好，細節描述可以通過與客戶或用戶進一步討論確認。每個用戶故事可以以用戶故事卡片的形式寫到開發團隊的任務看板上。用戶故事卡片的背面會記錄該用戶故事的驗收條件和可以確定故事完成的所謂定義或標準。

　　2.用戶故事的要點

　　用戶故事的基本格式是“作為（角色），我想要（功能），以此實現（商業價值）”。角色即為使用這個待開發系統的角色，功能是該角色的具體需求（Requirement），商業價值是最根本或深層次的需要（Need）。每個用戶故事要限制其大小，理想的情況是所寫的故事能夠讓一兩個程序員花半天到兩周時間完成代碼和測試。通常通過故事所對應故事點的多少來衡量完成每個故事的可能工作量。故事點是一個相對估計的方法，表明一個故事相對于其他故事的大小和復雜度。不同項目團隊的故事點的設定不盡相同，不具備彼此工作量的比較意義。開發團隊根據自身的速率（即每次迭代完成故事點的能力）來衡量把多少個用戶故事納入本次迭代。

　　3.用戶角色的建模

　　通過傳統PMP中涉及的頭腦風暴和名義小組會議等形式列出初始的用戶角色，通過親和圖來對所有用戶角色進行二次分類，最終確定待開發系統的用戶角色。通過應用敏捷項目管理的虛擬人物和極端人物的方法來編出可能遺漏的用戶故事。比如考慮同時擁有多個男友的女子想要額外的保密需求。

　　4.故事詳細的獲取

　　用戶故事一般是用業務語言寫成的句子，通常最好由用戶或客戶來寫。如果用戶不愿意寫的話，開發團隊可以通過訪談、問卷調查、觀察和故事編寫工作坊等形式來開展實施。故事編寫工作坊是快速捕撈故事最有效的方法，建議在開始每個發布計劃之前舉辦。通過工作坊畫出待開發系統內部高層級之間的交互關系，并構建可能的系統原型。需求一旦被合理的捕獲，產品經理和開發團隊可以對一些大的史詩故事（Epic Story）進行進一步裂解，通常分解為可在一次迭代中就可以完成的用戶故事，并且根據表征商業價值的不同對用戶故事進行優先級排序。最后，通過用戶故事地圖、發布計劃和迭代計劃等方法把用戶故事納入不同的發布或迭代中。