Scrum 中的「就緒定義」——它是什麼以及為什麼重要

終端用戶有時會提出新的功能想法或概念。此概念將以一個或多個大型故事的形式呈現，並由產品負責人加入到產品待辦事項清單。團隊將共同協作，找出如何將此概念轉化為一個或多個大型故事，然後精煉它們為更小、更清晰的使用者故事——作為實際的產品功能——這些將被納入下一個迭代的實施中。

產品負責人可以與團隊共同定義一個稱為「就緒定義」的文件，以確保待辦事項清單頂端的項目已準備就緒，可以進入迭代，讓開發團隊有信心在迭代結束前完成這些項目。

為什麼需要就緒定義？

就緒定義（DoR）是一組共同同意的標準，用來告訴所有人某件事何時已準備就緒可以開始——例如，當一個使用者故事已準備好進入迭代，或團隊開始迭代所需的所有必要條件均已滿足。一個明確的DoR能顯著提高Scrum團隊成功達成其迭代目標的機會。以下是一些結構良好之就緒定義可為團隊帶來的好處：

• 衡量待辦事項的「就緒」狀態
• 確保待辦事項已達到「足夠就緒」的程度
• 幫助團隊識別產品負責人或其他成員是否負荷過重
• 促進團隊成員之間的相互責任感
• 減少團隊在故事真正「就緒」前就必須承諾估算的壓力
• 減少開發過程中的需求偏移

範例——迭代的就緒定義

不同團隊可能對就緒有不同的定義——有些團隊需要的標準較少。例如，有些團隊僅需描述對使用者的價值、優先順序，並記錄如何展示它。估算與溝通發生在迭代規劃會議期間。以下是制定團隊就緒定義時可考慮的一些項目：

• 迭代待辦事項清單迭代待辦事項清單包含團隊承諾的所有缺陷、使用者故事及其他工作已優先排序
• 迭代待辦事項清單包含團隊承諾的所有缺陷、使用者故事及其他工作
• 無隱藏工作
• 所有團隊成員均已計算出其迭代容量
• 專案全職 = 每日 X 小時
• 所有使用者故事都符合「就緒定義」

範例 – 使用者故事的就緒定義

本節展示使用者故事的就緒定義範例，以及迭代就緒的範例。您可以將其中一些作為基線或起點。

• 故事明確說明其對使用者的價值。
• 故事的接受標準已明確定義。
• 已識別使用者故事的依賴關係。
• 交付團隊已接受使用者故事。
• 該 Scrum團隊接受使用者體驗的成果。
• 性能標準已依適當方式定義。
• 已明確指定誰將接受使用者故事。
• 團隊知道如何展示該故事。

總結

「就緒定義」這個術語並未在Scrum指南中說明，與其中內嵌的使用者故事和接受標準不同。也許您可以將就緒定義視為待辦事項精煉活動的一個組成部分，而非作為順序或階段門檻的檢查清單。待辦事項精煉是一個持續進行的過程，因此不限於單一事件——它是一項活動。