Scrum第六步：故事地圖

【Scrum故事地圖】
繼上篇企劃(PO)與團隊成員同步完初步資訊後，對於目標會有大概的輪廓，比較可以進一步把輪廓描邊出來，視覺化後提供給團隊進去細部討論，也就是產生看板的前製作業。

開發成員要執行的任務(TASK)，是從代辦清單(Product Backlog)挑選出來拆解，那如何產生Product Backlog呢?
有一部分如Scrum指南所說，是經驗導向的流程控制理論，

先假設你有一定的經驗後，依據過往經驗、知識來跑流程，再來修正調整，讓風險降低。"經驗導向"四個字也夠精簡有力哈!!

「不怕你做錯，但要從錯誤中學習到成長。」

據過往經驗，企劃很容易列出工作項清單，這沒問題，依照此方式列出後，團隊進行討論挑選。但還有更好的方式，那就是「使用者故事地圖User Story Map」。

剛跑敏捷狀態下，談USER太沉重，光是要讓企劃換位思考成User可能就要花點時間，何況是RD，思維轉換會打結或過於牛角尖，所以，我先姑且把USER拿掉，跟大家介紹時是以「故事地圖」稱呼，讓大家不至於新東西又糾結在"USER"這字眼上。

為何要在Product Backlog前，先用"地圖"來思考呢?
就好比出門旅遊時，我們很容易把要去玩的景點(目的地)訂出來，但如果只知道景點位置，要如何知道幾點要出發?
當然就是靠"地圖"來幫你把旅程、時間、路線粗估顯示，除了可以更清楚全貌掌握整體旅程外，通常還會再看看路程中，還有沒有遺漏想去玩的景點，或者中間補給、休息站要加入。

當把專案全貌視覺化後，在未來的變化中，就算動一髮牽全身也容易反應、應對，讓風險降到最低。
另外通常地圖會被長期保留下來，也就是過去做完的項目顯示，不僅可以看到歷程，也會有成就感驅動繼續前進，直到目的地，不就是"地圖(Map)"的吻合精神。

實際經驗：
1. 在大家都還不熟悉的情況下，第一次的地圖產生，會以SM+PO討論就好，先讓PO聚焦、理解後，後續再找團隊討論，而不用一開始大家一團亂中，發散後收斂不回來。記得，不要怕錯誤，記得要獲取經驗繼續向前。
2. 把USER拿掉，以習慣口語任務描述也行，熟悉故事地圖架構為主。
3. 依大家理解未來要做的項目，直覺的列出、分類、排序(經驗導向)，不求精確，只求輪廓。
4. 未來一定還會再重構一次地圖，視覺化方便團隊討論接下來要做的事，也大概清楚全貌目標。

結論：
套用"系統思考"：克服盲點、面對複雜性、見樹又見林的整體思考。
不然很容易在侷限的範圍，做出高成本的決策。

蠻多人已經有寫好 使用者故事地圖 的做法，去參考就好囉!!
USER 就是 PERSONA人物誌，又是另外一門學問了。
參考：
https://hk.saowen.com/a/3130a8eafb6a49ebe20cc1bacb68f670a5e9ac93db760f2eab7c60b208460416
https://www.uisdc.com/user-maps-design-ali-case
https://ruddyblog.wordpress.com/tag/%E5%A6%82%E4%BD%95%E5%89%B5%E5%BB%BA%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E5%9C%B0%E5%9C%96%E7%9C%8B%E6%9D%BF/
https://ruddyblog.wordpress.com/tag/%E4%BD%BF%E7%94%A8%E8%80%85%E6%95%85%E4%BA%8B%E5%9C%B0%E5%9C%96/
http://www.woshipm.com/pmd/375200.html
http://www.woshipm.com/pd/270289.html

補充：
地圖不一定要一次到位的完整，有個七分樣就行，留三分來隨時應變市場反應、任務變動調整。
一開始不見得就要把Release版本切好，除了花的時間過長外，也不見得符合日後的發展，尤其是在面對不曾碰觸過的市場。時間、資訊到了，SM再招集大家把Release定義，再把地圖重新排列一次。
例如：用"里程碑"概念來拆解Release，也是各對上進度表的概念。
前後端串接、分散系統、模擬、商務驗證、資訊整理。

上一步：Scrum第五步：目標探索-資訊同步
下一步：Scrum第七步：第零次回顧會議
Scrum過程總結