為了精準估算，你必須付出什麼代價？
研發團隊，常會被問到一個問題：
「請問一下，這個Ａ功能，大概要多久才能完成？」
這個問題，不會因為你跑的是敏捷，就自動免疫。那麼，身為經過敏捷思維洗禮的人，該如何做出合宜的應對？
我在 Agile Tour Kaohsiung 2018 開辦一場 2.5 小時的工作坊，帶領大家親自體驗這個議題。
不過，這個題材的背後，其實還有三段故事。
故事，要從一年半前講起。
改變／改革：流程與衡量指標
改革，很不容易；摧毀改革，卻很簡單。知名的改革框架，莫不注重改革的整合與固化。
敏捷亦然。像這篇文章〈慢慢的，公司内敏捷的热度就退了…..〉就訴說一則可悲的故事：
我並沒有告訴他們具體要怎樣做，只給了他們一些理論上的指導，然後他們就開始集思廣益，動手佈置。這其中展現出來的主動思考能力、自組織能力和執行力，讓我不由得暗地裡豎起大拇指。基於這樣良好的基礎，他們的敏捷過程推進的也非常順利，我輔導了他們 3 個月左右，他們已經熟練的掌握了一些實踐方法，加上本身已經具備的自組織能力和執行力，似乎繼續做下去，就可以達到不錯的成熟度。
Scrum 沒有明說的事：休耕期
Scrum 的官方白皮書 The Scrum Guide 非常輕薄短小（像 Nov 2017 版只有 19 頁），它的理念是：只制定最核心的原則、價值、角色、活動、產出物，其餘的則交給團隊根據經驗主義 1 去調適出最適合自己的細節。
想當然爾，有很多事，Scrum 並沒有明說。
那麼，沒有明說的事，就不需要做、就不能做了嗎？做了，就違反 Scrum 嗎？
這是許多奉 The Scrum Guide 為圭臬的人，常有的盲點。