Scrum產品Backlog详解

在最簡單的定義中，Scrum Product Backlog只是一個需要在項目中完成的所有事情的列表。它取代了傳統的需求規範工件。這些項目可以具有技術性質，或者可以以用戶為中心，例如以用戶故事的形式。Scrum Product Backlog的所有者是Scrum產品負責人。Scrum Master，Scrum團隊和其他利益相關者為其提供了廣泛而完整的待辦事項列表。

使用Scrum產品Backlog並不意味著不允許Scrum團隊創建和使用其他工件。其他工件的示例可以是各種用戶角色，工作流描述，用戶界面指南，故事板或用戶界面原型的摘要。但是，這些工件不會取代Scrum產品Backlog，而是補充和詳細說明其內容。

Scrum產品負責人在Sprint計劃會議期間使用Scrum產品Backlog來描述團隊的最佳條目。然後，Scrum團隊確定在即將到來的衝刺期間他們可以完成哪些項目。

每個Scrum Product Backlog都有一些屬性，可以將它與簡單的待辦事項列表區分開來：

• Scrum產品Backlog中的條目始終為客戶增加價值
• Scrum產品Backlog中的條目按優先順序排列並相應地進行排序
• 詳細程度取決於Scrum產品Backlog中條目的位置
• 所有條目都是估計的
• Scrum Product Backlog是一份活文檔
• Scrum產品Backlog中沒有操作項或低級任務

 

 

產品Backlog详解

只有增值的
條目Scrum產品Backlog中的每個條目都必須具有某種客戶價值。沒有任何客戶價值的參賽作品是純粹的浪費，無論如何都不應該存在。Scrum Product Backlog可以包括用於探索客戶需求或各種技術選項的條目，功能和非功能需求的描述，啟動產品所需的工作以及其他項目，例如設置環境或修復缺陷。某些任務可能無法為功能添加直接價值。然而，他們可以通過提高質量或減少長期事故來增加價值。

生活文件
Scrum Product Backlog在整個項目中進行了更改。如果需要，可以添加新要求，並且可以修改現有要求，更詳細地定義或甚至刪除。要求不再在早期凍結。相反，Scrum產品Backlog中的最終需求集也與所得軟件一起迭代開發。這與傳統的需求工程不同，但允許最大化客戶價值並最大限度地減少開發工作量。

不同層次的細節
Scrum Product Backlog中的要求具有不同的粒度。只有在下一個衝刺中應該實現的那些要求才會更詳細地定義，而其他所有要求都是粗粒度的。原因很簡單，將時間和精力投入到這些要求的規範中是沒有意義的，因為大多數這些要求在實施開始之前都會發生變化。

沒有低級任務
Scrum Product Backlog不包含詳細的需求信息。理想情況下，最終要求是在sprint期間與客戶一起定義的。這些要求的細分和分發是Scrum團隊的責任。

訂購Scrum產品Backlog
所有條目都按優先順序排列，並且訂購了Scrum Product Backlog。Scrum產品負責人在Scrum團隊的幫助下確定了優先級。增值，成本和風險是確定優先級的最常見因素。通過此優先級劃分，Scrum產品負責人決定接下來應該做什麼。

估計
所有條目Scrum產品Backlog中的所有條目必鬚根據商定的定義（例如故事點）進行估算。然後，可以使用此估計來確定Scrum產品Backlog中的條目的優先級，併計劃發布。

使用Backlog
積壓需要經常關注和關注 – 需要謹慎管理。在項目開始時，Scrum團隊及其Scrum產品負責人首先寫下他們能夠輕鬆想到的一切。對於第一次沖刺來說，這幾乎總是綽綽有餘。

在初始設置之後，必須在正在進行的流程中維護Scrum Product Backlog，其中包括以下步驟：

• 當發現新項目時，它們將被描述並添加到列表中。根據需要更改或刪除現有的。
• 訂購Scrum產品Backlog。最重要的項目被移到頂部。
• 為下一個Sprint計劃會議準備高優先級條目
• （重新）估計Scrum產品Backlog中的條目

Scrum產品負責人負責確保Scrum產品Backlog處於良好狀態，這是一個協作過程。當使用Scrum Framework時，大約10％的Scrum團隊應該保留總時間來維護Scrum產品Backlog（討論，評估等）。

Scrum Product Backlog的協作維護有助於澄清需求並從Scrum團隊中獲得支持。

Agile & Scrum Principles References

• The Agile Manifesto and Twelve Principles
• 10 Most Frequently Mentioned Basic Rules in Scrum