驗收標準 Acceptance Criteria

判斷功能是否完成的具體條件。

先用一句話理解

判斷功能是否完成的具體條件。

打個比方

像考試評分標準，避免每個人對完成的理解不同。

什麼時候會遇到

任何需要交付客戶或團隊驗收的功能。

再往深一點看

驗收標準（Acceptance Criteria）是讓 user story 變得可測試的那一步：它把「使用者想要什麼」轉換成「什麼行為、在什麼條件下、出現什麼結果算通過」。它和 user story 的關係是：一個 user story 通常對應多條驗收標準，每條描述一個可以被確認（人工或自動化測試）的情境。寫得好的驗收標準，讓工程師知道實作邊界在哪裡、讓 QA 知道怎麼測、讓客戶知道交付物是什麼——它同時也是 scope 在功能層級最細的體現。

舉個例子

User story 是「店員要能快速搜尋訂單」，對應的驗收標準可能是：輸入訂單編號後 1 秒內顯示結果；搜尋不到時顯示「查無結果」而非空白；搜尋框在手機上也能正常使用。這三條都可以逐一確認，而不是靠感覺說「搜尋功能做好了」。

常見誤解

- 用「好用」、「漂亮」、「流暢」這種無法測試的描述——沒人知道怎樣算通過，驗收時只能靠感覺吵架。
- 只寫正常流程，沒有寫失敗情境（例如：輸入錯誤時怎樣算通過），工程師就自己決定了，客戶驗收時才說「不是這樣」。
- 把驗收標準寫完就放在 PRD 裡不動，等功能改了設計或 scope 調整了，沒有同步更新，到驗收時拿舊標準對一個新設計，兩邊都對也都錯。