計劃，爲了更少的開發
故事地圖幫助大型組織建立共識。貫穿各個團隊的產品發佈地圖，可以幫助團隊以可視化的方式展示依賴關係。
大型用戶故事地圖解析：1、故事地圖的主幹在頂部；2、地圖要涵蓋整個發佈計劃；地圖要涵蓋貫穿多個用戶和系統的敘事主線。
提前發現可能造成損失的潛在風險是好事而不是壞事
需求範圍並沒有蔓延，而是我們對需求的理解更深刻了。
要做的事情太多，如何排定優先級？聚焦於系統外的預期成果來決定系統內需要什麼功能！！聚焦於成果，即產品發佈後用戶能使用和感知的東西，切分發布計劃應該以成果爲導向【針對MVP（最小可行產品）計劃】。聚焦於特定的目標成果，這是排定開發工作優先級的祕密。爲成果排定優先級，而非功能。
尋求最小的可用發佈集。一個可能的方法是，識別出哪些是基礎功能，哪些是降成本功能，哪些是攪局功能，哪些是差異化功能。
MVP到底是個什麼東東？
- MVP是指可以產生預期成果的最小產品發佈
- 最小可行方案是指可以產生預期成功的最小發布方案
- 最小可行產品是爲驗證假設而做的最小規模的實驗
對這個概念的理解至關重要。首先，MVP本身必須是個獨立的軟件，可以直接交付給用戶使用，並能產生價值的。其次，最小本身是個非常個性化和主觀的詞，如何確定最小？需要首先搞明白這個最小針對的是哪些用戶，這些用戶需要通過軟件來達成什麼目標。但無論如何，最小還是存在很大的猜測成分。既然是猜測，那就很可能猜錯了。那如何降低猜測帶來的風險呢？需要回答兩個問題：1）最大膽，風險最大的假設是什麼？哪些是最不確定的？2）爲了消除假設或者風險，需要哪些真實的信息？因此自然而然會得出一個推論：能不能通過快速調整策略，聚焦於學習，通過快速驗證第一個MVP的假設？就是說，能不能通過設置更小規模的實驗和原型來驗證我們對於最小和可行的假設呢？聯想到演進式架構中提到的假設驅動開發，和這裏的用戶故事正好可以呼應。
一組好問題，實際上項目也是這樣來對待需求的。
- 需求內容是什麼？
- 客戶是誰？哪些公司會採購這款產品？
- 用戶是誰？哪些人會用到這個產品，用這個產品來解決什麼問題？
- 購買和使用的動機是什麼？解決了哪些客戶和用戶當前無法解決的問題，使用之後又能獲得什麼樣的收益？
- 爲什麼要開發這款產品？如果開發出來併成功銷售，公司又能從中獲得什麼收益？