LeSS（Large-Scale Scrum） 是一種擴展型的敏捷方法，當一個產品需要多個 Scrum 團隊合作時，它強調：「多團隊也要像一個團隊一樣工作」。LeSS 的核心精神是：簡化結構、強化學習、強調全局觀與協作。

在 LeSS 當中，各個團隊會一起參與 Product Backlog Refinement（PBR），也就是需求釐清會議。這個活動的目的不是做設計，而是讓大家對「要做什麼」有共同理解，進而選擇哪些 Story 要拉進來開發。

SBE（Specification by Example）扮演什麼角色？

Specification by Example 是一種用「具體範例」來釐清需求的方法。它的重點不是寫測試，而是用真實情境幫助團隊對需求達成共識。

在 PBR 中運用 SBE 有幾個具體好處：
• 讓需求更具體，避免誤解：範例比一句話的描述更能表達清楚業務邏輯。
• 揭露模糊與假設：透過討論範例，團隊會發現彼此對需求的理解不同。
• 促進跨團隊協作與學習：不同專業背景的人，透過共同寫範例，理解彼此的思考。
• 為後續驗收與自動化測試打基礎：這些範例未來還能轉為驗收條件甚至測試腳本。

LeSS 提供了協作框架，PBR 是需求釐清的機會，而 SBE 則是讓需求真正「清楚起來」的工具。

週三下午，高鐵資訊系統部門的多個 Feature Team 聚在一起，準備開始 Product Backlog Refinement（PBR）。

這次 PO 小王準備了五個新 Story：
I. 旅客在訂票時可加購餐點
II. 完成付款後，自動寄送訂票與餐點明細 Email
III. 提供旅客查詢歷史訂單與餐點記錄的功能
IV. 在乘車前兩小時可取消餐點並自動退款
V. 系統需與第三方餐飲供應商 API 串接

Product Backlog Refinement Part I：

(1) PO 說明 Story

PO 小王沒有講太多技術細節，只強調每個 Story 背後想解決的「使用情境」與「旅客期待的結果」。例如：

• Story 1 是希望讓旅客在訂票當下，一併完成餐點選購，減少後續操作與排隊。
• Story 2 解決旅客對資訊透明的需求，避免訂餐成功卻沒收到確認信。
• Story 3 是讓回頭客能快速查詢歷史紀錄，提升服務體驗。
• Story 4 針對臨時變更的彈性需求，讓旅客可以取消餐點而不用致電客服。
• Story 5 代表背後整合的難點，要能與供應商溝通順利又穩定。

他提醒大家：這些故事不是要討論技術做法，而是要搞清楚「我們要讓旅客完成什麼事情」、「什麼情況下會讓旅客覺得出錯了？」

(2) 團隊初步討論：找出關聯

三個 Feature Team（鳴日隊、自強隊、太魯閣隊）開始針對這些故事交換看法。他們不是馬上跳到技術實作，而是問自己幾個問題：
• 哪些故事會在同一個使用情境中一起發生？
• 哪些故事雖然看起來獨立，實際上會有隱性依賴？
• 哪些故事現在資訊還不夠，需要更清楚的範例才能對齊理解？

經過短暫討論後他們決定：
• Story 1（加購餐點）與 Story 5（API 串接）彼此緊密相關，要一起釐清。
• Story 2（Email 寄送）經驗豐富的鳴日隊可單獨處理。
• Story 3（查詢記錄）相對獨立，由太魯閣隊接手。
• Story 4（取消餐點）有跨團隊關聯，納入多團隊 PBR 討論。

Product Backlog Refinement Part II：

(1) 從對話中發現真正需求

在多團隊 PBR 的場景裡，不再只是聽 PO 講需求，而是所有人開始丟出「如果是這樣，旅客會怎麼想？」、「這樣的情境，我們是不是還缺一個流程？」

初步範例（AC）產出：

A. 正面範例：
• 旅客訂了 12:00 的車票，在 9:00 AM 完成加購排骨便當的付款。
• 他預期會收到一封 Email，列出車次、座位、餐點明細與取餐地點。
• 如果 Email 沒收到，他會覺得是不是訂失敗了？所以系統要在付款頁面立即顯示完整資訊。

B. 例外情境：
• 若旅客訂的是來回票，他只選擇回程加餐。
• 討論中發現：目前系統沒有區分去程與回程餐點的欄位，這會導致餐點送錯段。
• 所以團隊補上需求：「系統應能識別各段票別的加餐設定。」

C. 異常情境：
• 第三方 API 回傳 HTTP 200，但實際 body 顯示餐點已售完。
• 一開始團隊只考慮 HTTP 錯誤碼，沒想到這種狀況也可能導致服務失敗。
• 最後補上明確 AC：「系統需解析回傳內容，確認供應狀態為 'available' 才算成功訂餐。」

D. 取消範例：
• 若旅客想在出發前兩小時內取消餐點，系統應提示「已超過可取消時間」並禁止操作。
• 團隊原以為只要有取消按鈕就好，現在才知道需要有時間邏輯判斷。

(2) 發現盲點

PBR 的對話不斷揭露大家原本的「假設」。例如：

• 有人以為旅客訂完票後一定會收到 Email，卻沒想到 Email 系統失敗時要不要重新送？
• 有人以為取消餐點只要改資料表，但沒考慮供應商那邊已經準備了餐點怎麼處理。
• 有人以為付款成功代表所有流程成功，但其實中間可能卡在餐點系統沒確認成功。

這些都不是寫文件能一開始就想到的，只有透過跨團隊的討論與範例驗證，才會一個一個被提出。

釐清需求，不是設計解法

PO 小王強調，PBR 的核心是釐清「我們要讓使用者完成什麼行為」，不是討論怎麼設計 API、畫面要長什麼樣。他說：
「一個需求清楚到不需要猜，就算工程師沒參加會議也能正確實作，那就夠了。」
他也提醒大家：

• 範例不是列舉測試用例，而是協助釐清行為邏輯。
• 討論時不要急著跳進怎麼做，要反覆問：『為什麼要做這個？旅客期望什麼？』
• 如果大家對故事的理解還不一致，就不能進 Sprint。

這場 PBR 雖然比預期長，但每一段交流都讓需求更加清晰，而這份清晰，就是高品質交付的開始。

為什麼要一起釐清需求？

從這場 PBR 中可以看出，將不同團隊聚在一起釐清需求有幾個明顯的好處：

• 建立共同理解與語言
不同角色原本用不同角度看事情，透過範例具體描述後，大家可以站在同一個使用者觀點對齊思維。

• 揭露隱藏假設與知識落差
你以為大家都知道的事，可能只有你知道。這場對話幫助團隊辨識盲點與知識斷層。

• 避免後期返工與誤解
越早釐清需求，越能減少日後因「想的不一樣」導致的誤解與重工。

• 強化學習與跨職能合作
每次的 PBR 就像一次現場實作的課堂，成員彼此學習別人的觀點與判斷，下一次能更快參與對話。

這不只是要開發出「能動的功能」，而是要確保我們做出來的，是「用戶真的需要的功能」。