Agile LEGO City Workshop 是一種用樂高城市模擬敏捷開發的團隊練習。這場公司內部課程由同事 Jed 發起，最有價值的地方不是把樂高城市蓋完，而是讓參與者在被退件、重新排優先順序、Sprint 驗收與會後檢討中，親身感受到敏捷開發為什麼重視溝通、變更、可交付成果與團隊信任。
Agile LEGO City Workshop 在練什麼？
Agile LEGO City Workshop 用樂高城市模擬軟體開發流程。參與者會在短 Sprint 中規劃、建造、驗收，體會需求理解與交付價值的落差。
這場工作坊把「城市」當成產品，把樂高積木當成開發材料，把主講人 Jed 當成產品負責人（Product Owner，PO）。團隊不是自由發揮蓋一座漂亮城市，而是依照客戶需求清單、優先順序與驗收標準，一輪一輪交付城市裡的功能。
Agile LEGO City Workshop 很適合用來體驗敏捷開發，因為樂高成果看得見、摸得到，PO 退件也會立刻發生。平常在軟體開發裡，需求誤解可能拖到測試或上線才爆開；在這個遊戲裡，門沒有面對道路、圓環不在市中心、托兒園離住宅太遠，都會在 Sprint Review 時馬上被指出。
敏捷開發宣言在這場工作坊中扮演什麼角色？
敏捷開發宣言是工作坊的價值觀底座。LEGO City 練習把個人互動、可交付成果、客戶合作與回應變化變成可觀察的行為。
工作坊一開始先讀敏捷開發宣言。敏捷開發宣言強調四組價值取捨：個人與互動、可用軟體、客戶合作、回應變化都比流程、文件、合約與固定計畫更需要被優先看見（Agile Manifesto，2001）。
這段對我來說很重要，因為 Scrum、站立會議、看板、故事點都只是做法。敏捷開發真正要保護的，是團隊能不能持續和客戶對齊，能不能接受需求改變，能不能把最有價值的成果先交出去。
| 敏捷價值 | 在 LEGO City 中的對應行為 |
|---|---|
| 個人與互動 | 團隊要先問清楚 PO 的驗收標準，而不是各做各的 |
| 可用的軟體 | 每個 Sprint 都要交出能被驗收的城市功能 |
| 與客戶合作 | PO 不是最後才出現，而是每輪都能提供回饋 |
| 回應變化 | 被退件後要調整下一輪計畫，而不是埋頭照舊做 |
Agile LEGO City Workshop 的規則怎麼設計？
Agile LEGO City Workshop 的規則包含需求清單、PO 問答、Sprint 計畫、看板追蹤與驗收計分。規則讓團隊把敏捷流程跑成一個短週期實驗。
遊戲開始前，團隊會拿到一張城市需求清單。需求越前面，代表客戶越重視。這個設定看似簡單，實際玩起來才會發現，團隊如果沒有先確認優先順序，就很容易先做自己覺得順手、好做、好玩的項目。
這場工作坊的基本規則如下：
- 依照需求清單建造客戶想要的樂高城市，排序越前面的需求越重要。
- PO 由 Jed 擔任，開始前可以提問，每個 Sprint 結束由 PO 驗收。
- 總共有 8 個 Sprint，每個 Sprint 開始前要先決定本輪要做的任務，並移到 To Do。
- 團隊用看板追蹤每個任務進度，包含 To Do、Doing 與 Done。
- 每輪用計分表比較 Sprint 計畫項目與實際驗收成功項目。
為什麼團隊一開始一直被 PO 退件？
團隊一開始被 PO 退件，主因是沒有真正理解客戶需求與驗收條件。交付順序、空間位置與細節規格都會影響成果是否有價值。
遊戲開始後，我們這組交付的任務一直被打槍。第一個 Sprint 交付平房，PO 不接受，原因是前面更重要的需求還沒交付；河濱公園安全設施因為圍牆沒有蓋滿被拒絕；接著又出現門沒有面對道路、沒有畫道路、圓環沒有在市中心、托兒園沒有臨近住宅等問題。
那個瞬間其實滿挫折，甚至會有點火大。但回頭看，這正是工作坊最像真實產品開發的地方。團隊以為自己有在做事，PO 看到的卻是「這個成果還不能解決客戶問題」。忙碌不等於交付價值，這句話在樂高桌上變得很具體。
會後檢討讓我學到什麼？
會後檢討的核心收穫，是敏捷開發需要承諾、責任與互相信任。團隊要定期反省，才能把退件經驗轉成下一輪改善。
我覺得會後檢討是整個遊戲最精華的部分。Jed 特別再為我和 Jack 做了一次報告，讓我有機會聽到完整的整理。大家提出最多的感想，是一開始沒有搞清楚客戶需求，也沒有先把整座城市做完整規劃，導致產品一直無法即時 release。
Jed 接著帶我們看敏捷開發原則。敏捷開發原則裡提到，團隊應透過早期與持續交付有價值的軟體滿足客戶，也要歡迎需求變動、頻繁交付、讓業務與開發成員一起工作，並在規律的反覆之間檢討如何變得更有效率（Agile Manifesto，2001）。
這些原則落到 LEGO City Workshop 裡，可以被整理成三件事：
| 工作坊情境 | 對應的敏捷原則 | 我帶走的提醒 |
|---|---|---|
| 一開始做錯優先順序 | 先交付對客戶有價值的成果 | 不要只做團隊覺得好做的功能 |
| 多次被 PO 退件 | 歡迎需求變動與持續檢查 | 退件不是羞辱，而是更早知道偏差 |
| 每輪重新估算與調整 | 團隊定期自省並修正做法 | 速度要從真實完成量推回來，不是用希望值填滿 |
敏捷在這裡不是儀式，而是一組價值觀。Scrum 是敏捷開發的一個框架，Daily Scrum 是 Scrum 裡的事件之一；如果團隊沒有承諾、責任與互相信任，再多儀式也只會變成形式。
Sprint 估算為什麼要看故事點，而不是人天？
Sprint 估算看故事點，是為了理解團隊能交付多少客戶價值。人天偏向成本視角，故事點更適合用來調整產品開發節奏。
過去估算專案時，我們常用「人／天」來看成本。但敏捷開發裡更常談故事點，重心不是問「這件事要花多少人力成本」，而是問「這項需求對客戶有多少價值、複雜度多高、這個 Sprint 有沒有可能完成」。
每個 Sprint 只規劃本輪要做的事，並把客戶需求切到足夠小。團隊成員一起估算任務點數，如果估算差異太大，就回頭討論原因。Sprint 結束後，再比較原本承諾的點數與實際完成的點數，用真實完成量調整下一輪。
這也是敏捷開發重視穩定團隊的原因。團隊越穩定，默契、判斷與估算校準越容易累積；團隊一直大幅變動，Velocity 就很難成為可用的規劃依據。
這場工作坊適合用在哪些團隊訓練？
Agile LEGO City Workshop 適合用在敏捷導入、產品開發訓練與跨職能溝通練習。工作坊能讓團隊用低風險方式看見流程問題。
我會把 Agile LEGO City Workshop 放在「讓團隊先感受問題」的位置，而不是把它當成完整 Scrum 教學。工作坊可以讓參與者快速看見：需求沒有問清楚會怎樣、優先順序不一致會怎樣、Done 不等於 Accepted 會怎樣。
適合使用的情境包括：
| 團隊情境 | 工作坊能帶出的討論 |
|---|---|
| 剛開始導入敏捷 | 什麼是 Sprint、PO、驗收與回顧 |
| 開發與產品常常對不上 | 需求描述、優先順序與驗收標準要怎麼說清楚 |
| 團隊習慣一次做太大 | 為什麼要把需求拆小、短週期交付 |
| 估算常常失準 | 為什麼要用真實完成量校準下一輪承諾 |
這場工作坊最好的地方，是讓團隊在沒有商業風險的環境裡犯錯。真正回到專案時，那些被 PO 退件的記憶會提醒自己：先問清楚價值，再開始動手。
延伸閱讀
如果想把 Agile LEGO City Workshop 的心得延伸到產品規劃、原型驗證與介面設計，下面幾篇站內文章可以接著看。
- Marty Cagan 談產品系列影片心得
- 產品體驗設計概念介紹
- 外行人也能學會的 App 企劃法
- 行動裝置使用者介面設計：從使用者研究到視覺流程的讀書筆記
- AI 原型程式開發工具怎麼選？v0、Bolt、Replit、21st.dev、shadcn/ui、Lovable 介紹
常見問題
Agile LEGO City Workshop 是什麼？
Agile LEGO City Workshop 是用樂高城市模擬敏捷開發的工作坊。團隊在短 Sprint 中依需求清單建造城市，並由 PO 驗收成果，藉此理解需求、優先順序、交付與回顧。
Agile LEGO City Workshop 和 Scrum 有什麼關係？
Agile LEGO City Workshop 會用到 Scrum 常見概念，例如 Product Owner、Sprint、看板、驗收與回顧。不過 Agile LEGO City Workshop 本身是練習活動，不等於 Scrum Guide 的完整框架。
Agile LEGO City Workshop 可以學到什麼？
Agile LEGO City Workshop 可以學到需求確認、價值排序、短週期交付、團隊估算與回顧改善。最直接的收穫，是理解「做完」不等於「客戶接受」。
敏捷開發為什麼重視客戶價值？
敏捷開發重視客戶價值，因為團隊時間有限，應先交付最能解決客戶問題的成果。LEGO City Workshop 裡，先做低優先順序項目就會被 PO 退件，這讓價值排序變得很容易理解。
Sprint 估算一定要用故事點嗎？
Sprint 估算不一定只能用故事點，但故事點能幫團隊討論相對複雜度、風險與工作量。重點不是點數本身，而是用每輪真實完成量調整下一輪承諾。
Agile LEGO City Workshop 適合非工程團隊嗎？
Agile LEGO City Workshop 適合非工程團隊，尤其是需要跨部門合作、需求釐清與短週期交付的團隊。只要工作包含需求、優先順序、驗收與回饋，就能從這類模擬活動中學到流程觀念。
參考資料
- Agile Manifesto, Manifesto for Agile Software Development，2001，存取日期：2026-08-28。
- Agile Manifesto, 敏捷宣言背後的原則，存取日期：2026-08-28。
- Scrum Guides, The 2020 Scrum Guide，2020-11，存取日期：2026-08-28。
- Jed, 我對Daily Scrum的理解與看法，2018-01-20，存取日期：2026-08-28。
- SlideShare, Scrum Simulation with LEGO, Agile Game，存取日期：2026-08-28。
- funevo, 閉嘴也不錯：如何用靜音排序 Mute Mapping 快速估算需求，2015-11-16，存取日期：2026-08-28。
最後更新
本文最後更新於 2026-08-28。這次整理保留 2018-02-22 的 Agile LEGO City Workshop 參與心得、PO 退件經驗、Sprint 估算觀察與會後檢討，補上 GEO Answer Blocks、FAQ、參考資料、站內延伸閱讀與本機圖片路徑。
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2018-02-22