用戶故事和驗收標準有什麼區別？

完成的定義 (DoD) 是用戶故事必須遵守的要求列表，以便團隊稱其為完成。 而用戶故事的 驗收標準 由一組測試場景組成，需要滿足這些測試場景以確認軟件按預期工作。

這兩者之間的區別在於，  DoD 對所有用戶故事都是通用的，而驗收標準適用於特定的用戶故事。每個用戶故事的接受標準將根據該用戶故事的要求而有所不同。

換句話說， 為了完成用戶故事，必須同時滿足 DoD 和驗收標準。 除非這兩個列表都完成，否則產品增量不被認為是完整的。因此，我們需要定義完成定義（DOD）的兩個方面——完成標準和驗收標準：

完成的定義

完成的定義是一個項目列表，每個項目都用於驗證一個故事或 PBI，它的存在是為了確保 開發團隊 就他們試圖生產的工作質量達成一致。它作為一個清單，用於檢查 每個 產品待辦事項 （又名 PBI）或用戶故事的完整性。“完成”定義中的項目旨在適用於產品待辦列表中的所有項目，而不僅僅是單個 用戶故事。可以概括如下：

• 該術語更適用於整個產品增量
• 在大多數情況下，該術語意味著產品增量是可 發貨的
• 該術語在 Scrum 指南中定義
• 用作團隊成員之間交流的一種方式
• 整體軟件質量
• 增量是否可發貨

完成定義的目標

• 在團隊內部建立關於質量和完整性的共識
• 用作檢查用戶故事（或 PBI）的清單
• 確保在Sprint結束時交付的增量  具有高質量，並且所有相關人員都很好地理解了質量。

示例——完成的定義

例如，在軟件行業，團隊可能需要提出以下一些問題來提出他們的 DoD：

• 代碼同行評審？
• 代碼完成了嗎？
• 代碼審查？
• 代碼簽入？
• 單元測試通過了嗎？
• 功能測試通過了嗎？
• 驗收測試完成了嗎？
• 產品負責人 審核並接受？

驗收標準

用戶故事是敏捷開發的主要開發 工件 之一 ，但 Scrum 並沒有明確要求使用用戶故事或驗收標準。如果一個產品 backlog 項目被認為太大而無法放入 sprint，通常會分解為用戶故事，隨後分解為一組任務，如圖所示：

用戶故事封裝了驗收標準，因此我們經常看到完成和驗收標準的定義在我們的 Scrum 開發過程中並存。用戶故事提供了團隊應交付的功能的上下文。驗收標準提供了有關所述功能的詳細信息以及客戶如何接受它們的指導。他們兩個一起提供了整個可交付成果。

一些驗收標準將在 Sprint 開始之前的 Ongoing Backlog Refinement 事件中發現，而其他驗收標準將在 Sprint 計劃之後 當坐下來就小團隊中的用戶故事進行對話時發現。因此，驗收標準是用戶故事或產品待辦事項項所獨有的屬性。

• 該術語適用於單個 PBI/故事
• 每個 PBI/故事的接受標準都不同
• Scrum 指南中沒有定義術語
• 用作向所有相關人員傳達已滿足特定 PBI/故事要求的一種方式
• 又名驗收測試，滿足條件，在某些情況下是“測試用例”等

驗收標準的目標

• 明確團隊在開始工作之前應該構建什麼
• 確保每個人都對問題有共識
• 幫助團隊成員知道故事何時完成
• 通過自動化測試幫助驗證故事。

示例——驗收標準

• 用戶在未完成所有必填字段的情況下無法提交表單
• 表格中的信息存儲在註冊數據庫中
• 可以通過信用卡付款
• 提交表單後，將向用戶發送確認電子郵件

具有接受標準的用戶故事示例

下圖顯示了一個用戶故事的驗收標準示例。

參考

• 完成與驗收標準的定義
• 什麼是用戶故事映射？
• 敏捷軟件開發的用戶故事與用例