為了精準估算，你必須付出什麼代價？

研發團隊，常會被問到一個問題：

「請問一下，這個Ａ功能，大概要多久才能完成？」

這個問題，不會因為你跑的是敏捷，就自動免疫。那麼，身為經過敏捷思維洗禮的人，該如何做出合宜的應對？

我在 Agile Tour Kaohsiung 2018 開辦一場 2.5 小時的工作坊，帶領大家親自體驗這個議題。

不過，這個題材的背後，其實還有三段故事。

故事，要從一年半前講起。

第一段故事：結構化流程

一年半前，我曾提過一個心願：

我想用結構化的 Sprint Planning 流程，讓錨定效應、以關係為中心、目的型談判自然發生，讓參與其中的人，逐漸在刻意不遮掩的建設性衝突中，潛移默化。¹

這個心願，即使我今年已經將自己的招牌課程【敏捷原理與團隊塑造】進化到二日版 ²，也都還未能夠實現。要完整實現，恐怕得擴充至二天半，甚至三日版。

這是一個小缺憾。

年底正好有個在 Agile Tour Kaohsiung 2018 舉辦工作坊的機會，我就來小試一下心中設想的「結構化的 Sprint Planning 流程」，以後再看看有沒有機會將這次經驗併入招牌課程。

第二段故事：衡量

設計工作坊，要先定義好最核心的體驗內容。

Sprint planning，或者 release planning，都有一個共同議題：衡量。正好這陣子我一直在研究這類衡量、指標等相關議題 ³，便將工作坊的題目訂為【為了精準估算，你必須付出什麼代價？】。

核心的體驗內容決定好了，體驗的動線，則以《如何衡量萬事萬物》這本書做為參考標的。

第一次看到這本書名，是在《精實企業》及《精實執行》。能同時被這兩本經典引述，想必非泛泛之書。

當時只覺得可以從中借用到一些衡量妙法，像是費米推論之類的。萬萬沒想到，這簡直是改變三觀的奇書。恰好又跟我這陣子在系統閱讀的主軸相吻合，讀來可說是點頭如搗蒜。

看懂這本書，內化並實踐，有助於從根本解決一些盤根錯節的敏捷持久落地的企業面難題。

初步啃完這本奇書，就花了我好幾天，累積起來共十七個小時。十七小時的心得，在短短的 2.5 小時的工作坊是無法盡數展現出來的，我只能先揀選一個雖粗淺但稱得上是全貌的流程，作為工作坊的體驗主動線。

第三段故事：PDCA

核心的體驗內容決定好了，體驗的動線也決定好了，就剩下體驗的劇本了。

既然要辦的是工作坊，重點自然不是說教，而是體驗，而且是能成為肌肉記憶的體驗。

這一點比較簡單。自從經過【體驗式課程的遊戲設計與操作實務】的洗禮 ⁴，我將招牌課程【敏捷原理與團隊塑造】調整成「高速高頻率 PDCA 循環」的風格，廣受好評，已成為自己的拿手招術。

因此，我決定這次的工作坊，也比照辦理。

在敏捷世界裡，不管是 sprint planning 還是 release planning，都很強調全員參與。因此，我的工作坊劇本也設計成要全員參與，以反應真實情況：

在這兩個半小時的體驗活動中，我會用真實案例的改編版本，帶大家體驗 Sprint Planning 及 Backlog Refinement 的核心要素。不管你是 PO、PM、UX、RD、QA，都能從活動中親自體認到，我們到底有沒有必要追求精準的估算？以及，萬一真的有必要，我們又該做什麼樣的準備？

分組方法有很多，有安全穩當的，也有刺激難以掌控的。當天在 Agile Tour Kaohsiung 2018 活動現場，看到大家非常專業，便臨時起意，將現場人士分成三大組：Scrum Master 組、PO 組、developer 組。

非常冒險的決定。但，敏捷，本來就是要冒必要的險嘛！

整場 2.5 小時的活動，有笑聲，有吵架聲激辯聲（過程中一度擦出火花），也有嚴肅的制憲大會——像極了真實的職場情境：

感謝超強的參與者，尤其是始料未及的 Scrum Master 組，讓我這場首發的工作坊，得到超出我預期的效果／笑果。

「高速高頻率 PDCA 循環」風格，在這 2.5 小時中，應該算是嚴格貫徹了。

未央歌

一年半前許下的心願「結構化的 Sprint Planning 流程」，這次 2.5 小時的工作坊，大約實現了六成。

要完全實現，全程可能要 3 小時。

在改版成功之前，先貼出這場 2.5 小時 Workshop 可公開的部分。

下一步呢？請靜待吧。