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. 依大家理解未來要做的項目,直覺的列出、分類