Scrum:如何細化產品待辦列表?

並非產品待辦列表中的所有項目都會同時具有相同的大小和詳細程度(即功能/史詩/用戶故事和任務)。我們計劃很快開展的 PBI 應該接近待辦事項的頂部,體積小且非常詳細,以便可以在近期的 sprint 中開展工作。我們在一段時間內不會處理的 PBI 應該位於待辦事項的底部,尺寸更大,細節更少。

用例/功能 是您的最終用戶將擁有的他們以前沒有的功能。例如,通過手機在線購買商品將是一項功能。您的產品路線圖通常包含功能級別的要求。

史詩 是將功能分解為可操作需求的下一個階段。它們是與功能相關的一系列操作。使用信用卡通過手機從購物車中購買商品的能力將是史詩般的。它比功能(在線購買商品)要小,但它比單獨支持購買商品的單個信用卡集成要大。我們不允許將比史詩更大的需求納入發布計劃。

用戶故事 是最小的需求形式,仍然可以獨立存在。用戶故事由一項價值行動或一項價值整合組成。例如,使用 Visa 卡通過手機從購物車中購買商品就是一個用戶故事。使用萬事達卡購買商品可能是不同的集成,因此可能是不同的用戶故事。用戶故事足夠小,可以添加到 sprint 中並開始開發。我將在接下來的部分中詳細介紹用戶故事。

任務 是實現用戶故事所需的內部步驟。在 sprint 計劃期間,用戶故事被分解為任務。雖然需求是最終用戶所做的事情,但任務是開發團隊為使需求工作所做的事情。

產品待辦事項 (PBI) 的粒度級別

該圖描述了不同層次的需求分解,以適應開發路線圖的一系列衝刺

如何細化產品待辦列表?
  • 上圖的頂部是橙色的、最大的磚塊。它們代表系統要實現的業務目標,即用例或用戶功能。
  • 下一個級別是大於單個 sprint 但小於發布的 PBI。讓我們將此級別的 PBI 稱為史詩。
  • 在第三級,我們發現 PBI 的大小適合 sprint ——它們可以在幾天而不是幾週內完成。這些項目符合團隊的 就緒定義, 可以表示為用戶故事。
  • 在最低級別,這些 PBI 可以選擇性地從用戶故事分解為任務,並在單次迭代結束時交付。

產品積壓

產品待辦列表列出了所有需要的可交付成果。其內容按業務價值排序。如上所述,最重要的項目顯示在產品待辦列表的頂部,因此團隊知道首先要交付什麼。待辦事項項目的優先級可能會發生變化,可以添加和刪除需求——因此,產品待辦事項是一個持續維護的計劃,以實現不斷增長的業務價值。

產品待辦事項

產品待辦事項 (PBI) 是構成產品待辦事項的元素。產品待辦列表項的範圍可以從規範和要求,到用例、史詩、用戶故事,甚至是錯誤,或 有時間限制的 研究任務。

產品待辦列表項細化

衝刺計劃流程

 通常需要準備 Sprint 計劃,以確保產品 Backlog 已被細化到適當的詳細程度,並帶有估計和驗收標準 (這是產品 Backlog 細化的目的)。如果在產品Backlog細化過程中對Product Backlog Items進行了分析和思考,那麼在Sprint Planning會議中最優先的Product Backlog項目可以很好地理解和容易選擇。

概括

Product Backlog Refinement 過程的目標是讓 Product Backlog 項目處於準備好的狀態以進行 sprint 計劃,因此產品 backlog 項目是:

  • 團隊中的每個人都足夠清晰易懂
  • 小到足以包含在 sprint 中

其他推薦的 Scrum 文章

Leave a Reply

發佈留言必須填寫的電子郵件地址不會公開。