Scrum 中就緒的定義

最終用戶有時對新功能有想法或概念。概念表示為一個或多個功能項，並由產品所有者添加到產品積壓中。團隊將共同努力，找出如何將這一概念轉化為一個或多個史詩，然後將其細化為更小、更清晰的用戶故事，並將其作為真正的產品功能納入下一個 sprint 實施。

但是，確保在 sprint 之前準備好用戶故事可以對團隊生產力產生直接而重大的影響。有一個“準備好”的定義意味著故事必須立即準備好實施。團隊必須能夠確定需要做什麼以及完成用戶故事所需的工作量

團隊會將產品 backlog 頂部的故事拉到 sprint backlog 中。這些故事必須“準備好”。有些公司實際上需要一份詳細的清單來確定一個故事是否“準備好”，而不僅僅是“幾乎”。

如何創建就緒的定義？

產品負責人可以與團隊一起定義一個 稱為“就緒的定義”的工件 ，以確保積壓工作頂部的項目已準備好進入 sprint，以便開發團隊可以自信地提交並完成它們衝刺的結束。

為什麼要定義就緒？

就緒的定義是一組讓每個人都知道什麼時候可以開始的協議，例如，當用戶故事準備好進入衝刺時，或者當所有必要條件都適合團隊開始衝刺時。對就緒的適當定義將大大提高 Scrum 團隊成功實現其 sprint 目標的機會。以下是結構合理的 DoR 可以為團隊帶來的一系列好處：

• 衡量積壓項目的“就緒”狀態
• 確保產品積壓項目已被“恰到好處”考慮
• 幫助團隊確定產品負責人或其他團隊成員何時不堪重負
• 讓團隊相互負責
• 在故事“準備好”之前減少團隊承諾估算的壓力
• 減少開發中的“需求流失”

示例 — 為 Sprint 做好準備的定義

不同的團隊會有不同的準備好牙列，有些需要的更少。即，一些團隊只是向用戶描述價值、優先級和編寫演示方法。其他估計和溝通在 sprint 計劃會議 等中。以下是為您的團隊開發 DOR 時要考慮的示例項目：

• Sprint  Backlog 優先
• Spring Backlog 包含團隊承諾的所有缺陷、用戶故事和其他工作
• 沒有隱藏的工作
• 所有團隊成員都計算了他們的 Sprint 容量
• 全職項目 = 每天 X 小時
• 所有用戶故事都符合就緒的定義

示例 — 為用戶故事做好準備的定義

本節展示了一個用戶故事就緒的示例定義，以及一個 Sprint 就緒的示例定義。您可以採用其中一些作為基線或起點：

• 故事對用戶的價值是明確的。
• Story的 驗收標準 已經明確描述。
• 已識別用戶故事依賴項
• 交付團隊規模的用戶故事
• Scrum 團隊接受用戶體驗工件
• 酌情確定績效標準
• 確定將接受用戶故事的人
• 團隊知道如何演示故事。

概括

Scrum 指南中沒有描述術語“就緒的定義”。它與嵌入其中的用戶故事和驗收標準相同。或許您可能認為準備就緒的定義是產品待辦列表細化活動的一個組成部分，而不是使用準備就緒的定義作為序列和階段門清單。Backlog細化是一個持續的過程，因此它不限於一個事件，而是被視為一個活動。