還記得我們在前面有講過「怎麼管理不同顆粒度的 Product Backlog」嗎？裡面有提到我們將產品開發檢視的顆粒度大致分為三個層級：

1. 檢視使命、產品目標與策略的 Product Roadmap
2. 檢視策略與目標的 Release Plan
3. 檢視近期開發的 Product Backlog 與 Sprint Backlog

在第三個層級，是我們最常面對的，這系列文花了很大的篇幅去用實體卡紙與 Jira 描述我們怎麼去讓這層顆粒度透明出來，讓我們在 Scrum 事件得以檢視與調適。那這兩天就來聊聊前面兩個層級該如何進行。

我們先往上一層級走，來聊聊 Release Plan 吧。過往我們如果只聚焦於第三個層級的顆粒度，那往往會變成見樹不見林，團隊不知道我們是為何而戰，只知道需求不斷來，好像永無止盡，這也是我常聽到 Scrum 被抱怨的、被誤解的點。

我認為在這些迭代週期背後，通常都會有一個目標，我們就是為了這個目標去展開數個迭代的開發。我們會決定在接下來的時間裡，專注在這個目標上，然後預計會使用幾次衝刺，來達到什麼樣的成效。就如經典的時間、成本、範圍的三角，我們這個目標固定了時間與成本，接下來就來聊聊範圍的調整吧！

在這個目標要開始開發前，我們一樣會如同之前所說去做 Impact Mapping 與 User Story Mapping，前者確立了我們的聚焦點與影響範圍，後者揭示了我們對這個目標的全貌。我們透過後者的成果去請團隊做了簡單的估算，並且按照商業考量訂了不同的 Release 階段——丁字褲、 MVP、MMP、Good to have。

有了這些資訊，我們就會評估按照過去速率表累積的經驗，配合估算出來的點數，大概能夠預測我們會需要 n ~ m 個 Sprint 才有辦法完成。接著聊聊我們是不是能夠接受，不能接受我們就可以展開對話去思考，在保有最核心的 outcome 下，我們能不能有更小的 output 作為範疇。

等到這些 output 大致抵定後，我們就會將他們從 user story mapping 抽出，開始排 Priority。我會將 m 個 sprint 寫出來，讓團隊與 PO 按照 Priority 排進這些 Sprint 裡，預期那一個個 sprint 我們該完成到哪裡。目的不是給承諾、畫死線，而是創造出類似燃盡圖的效果。

這樣的排序可以讓我們更近一步的感受可行性，進而展開更多對話。另外也是對我們的這樣範疇有一週週的預期。這就會是我們這個目標的 release plan。

當我們現實偏離預期時，就是該展開對話的時候，這也是 Release plan 他發揮透明度的展現。

我們會在每次 Sprint Review 檢視 Product Backlog 的環節先檢視 Release Plan，讓我們檢視現況與期待的落差，進而討論如何調整，通常會是捨棄部分的範疇。

Release Plan 我們第一次做的時候是在團隊房間外的牆上，透過便利貼與我們稱為 Story Card 的卡紙共創出來的。

但在 WFH 時，這樣的實體展現就不得不轉到數位的方式。所以我會透過 Product Backlog 的另外一個快樂小夥伴 —— Miro 建立。