面對瞬息萬變的市場需求以及需求實現的不確定，相比於按部就班的瀑布流開發方法，敏捷開發的方法更適用於範圍不確定和時間固定的產品背景之下進行產品研發。從計劃驅動到價值驅動，敏捷如何應用到產品規劃的過程中呢？以下從團隊和流程2個角度來詮釋產品規劃的敏捷。
首先，產品規劃是多個部門協作的結果
產品規劃流程
1.產品立項會
2.願景、目標用戶討論、商業模型討論
3.創建用戶畫像、用戶流程圖
4.創建用戶故事、討論可行性
5.用戶故事彙報會（若不通過返回到第3步）
6.功能和內容確定會
涉及部門和人員
產品部門
全程參與
制定溝通計劃
組織會議和活動
整理溝通結構，彙集就信息，形成報告
製作原型並和相關部門討論可行性
創建用戶流程圖
創建“大”用戶故事
項目干係人
部門參與（1、2、5、6）
參與關鍵會議，並在會議中行使否決權
對項目提供資金支持
幫助項目團隊獲取管理層的關注
開發部門
部分參與（1、2、4、5、6）
針對產品的功能提出建議，並與產品經理討論功能的可行性，提出更好的解決方案
設計部門
部分參與（1、2、4、5、6）
針對產品的功能和內容提出建議，與產品經理討論用戶的體驗流程，並針對產品的關鍵點給出體驗優化方案
運營部門
部分參與（1、2、6）
需要時刻了解進度以及討論結論用於提前制定運營策略
明確不同部門之間的參與程度，一方面可以同步進度，另一方面節約時間，提高效率。清晰的流程將每個部門的權責理清，保證產品產品規劃高效進行。
如何進行產品規劃？
1.確定產品的範圍（什麼該做，什麼不做）
2.產出用戶故事（做什麼）
1.確定產品的範圍
產品範圍的三個角度：業務角度、用戶角度、內容角度
業務角度：分析產品的信息架構
1.用戶研究和分析
2.信息分類
3.創建信息架構地圖
4.創建信息架構標籤
5.提取、創建元數據
6.數據建模
用戶角度：
1.哪些羣體使用？他們是什麼角色？他們會怎麼用？
2.先分析用戶羣體的需求，然後分析該羣體中某角色的需求
內容角度
產品的內容在一定程度上會反過來影響產品的功能
識別子系統
1.爲什麼要識別子系統
子系統是粗粒度的產品範圍的體現
項目干係人和項目小組瞭解子系統後，會對整體系統有高層次的認識
2.識別子系統的方法
使用功能結構圖和流程圖
2.產出用戶故事
1.製作用戶流程圖
使用泳道圖產出跨子系統的用戶流程圖，隨後分別製作各子系統的用戶流程圖
泳道圖可以快速得知不同對象的功能以及功能之間的前後關係
涉及到外部跳轉的時候，至少需要一個步驟（功能點）
當涉及到轉折點，或者信息狀態發生變化，需要一個步驟（功能點）
2.製作MVP
根據主流程識別MVP，將功能做刪減
採用MoSCoW法則將功能點分類：
•Must Have：指一定要有的功能
• Should Have：指應該有的功能
• Could Have：指可以有的功能
• Won't Have：指（此版本）不會有的功能
在實際應用中，Must Have比較好識別，對於Should Have和Could Have可以採用“價值和實現難度”矩陣識別和歸類：
用戶價值高，難度低，優先製作；
用戶價值低，難度高，延後製作甚至不做；
用戶價值高、難度高和用戶價值低和難度低：延後製作；
注意：開發部門可能出於識別、規避風險的考慮，會先做“難度高，價值高”的功能
3.製作線框流圖
製作線框圖，並組合到MVP流程中，得到“線框流程圖”
線框流圖的意義在於：
• 既能夠展示出用戶使用流程；
• 又能夠將用戶體驗的元素展現出來；
4.編寫“大”用戶故事
根據MVP地圖和線框圖，產出“大”用戶故事，隨後組織會議討論並達成一致
5.拆分“大”用戶故事
拆分“大”用戶故事爲“可開發”的用戶故事，並配合研發部門進行開發
用戶故事驗收會議
爲什麼要組織用戶故事驗收會議？
“大”用戶故事將被拆分爲數個小故事，在拆分以前，必須確認他們是必要的
驗收會議能夠確保不會有“大”用戶故事被遺漏
誰主持？誰參加？
• 產品經理主持會議
• 項目團隊、相關團隊、項目干係人都需要參加
會議後的產出物是什麼？
• 經過集體確認的“大”用戶故事
• 項目干係人確定其必要性
• 相關團隊確定其合理性
• 開發團隊確定其可行性
• 會議後，產品團隊即將其拆分爲“可開發”、“小”的用戶故事
拆分方法
方法一、按照流程進行拆分
方法二、從簡單到複雜的拆分
方法三、按照操作邊界拆分
方法四、按照數據邊界拆分
方法五、按照個性、共性拆分
共性的需求可能包括：
• 安全處理
• 錯誤處理
• 日誌處理