zh_TW 繁體中文

Scrum工件：產品Backlog，Sprint Backlog和產品增量

Scrum工件

Table of Contents hide
1 Scrum工件
2 產品積壓 (Product Backlog)
3 Sprint Backlog
4 產品增量 (Product Increment)
5 Scrum Artifact Articles

3種類型的Scrum工件包括：

  • 產品積壓
  • Sprint積壓和
  • 產品增量

scrum artifacts visual paradigm的圖片搜尋結果

現在我們將看到這些術語的含義以及如何創建這些工件。

產品積壓 (Product Backlog)

簡而言之，產品待辦事項列表中包含產品所需的所有內容。這是scrum團隊提供的與產品相關的最終文檔。它是產品所有者（PO）擁有的有序商品清單。

PO負責創建，維護和優先排序此列表。PO使用此產品積壓來解釋在sprint團隊沖刺期間需要完成的最高要求。

此列表中的項目可能是也可能不是技術語言。它甚至可以是外行的語言，但它應包含所有產品要求和隨附的更改。此外，產品積壓並不意味著scrum團隊只會跟隨這個工件。

他們可以創建自己的詳細工件，但這些工件不會與產品積壓相矛盾或取代。他們寧願與產品積壓要求保持一致。

以下是典型產品待辦事項的示例：

故事 估計 優先
我想登錄 4 1
我想退出 2 2
我想更改密碼 1 3
我想更新地址 3 4
我想添加一個新的家庭電話號碼 1 五

這給我們帶來了一個問題，如何創建一個好的產品積壓？

產品積壓理想情況下應遵循以下規則：

（i）應優先考慮 – 產品積壓中的項目應按其優先順序排序。這個優先級可以由PO和Scrum團隊共同決定。優先級因素可以是故事點的好處，創建所涉及的工作，複雜性，客戶優先級等。

它有助於團隊了解需要首先交付的內容。

（ii）應該估計 – 故事應該按照商定的定義進行估算，無論可能是什麼。這也可以用於優先級排序。

（iii）它應該是高級別的 – 產品積壓中的故事應該是高級別的，不應該進入細節。根據要求創建詳細的用戶故事取決於Scrum團隊而非PO。

（iv）它應該是動態的 – 產品積壓不是最終的靜態文檔。當PO接收來自Scrum團隊的輸入並且客戶需求變得越來越清晰時，應該重新審視它。因此，文檔要求在開始時不會被凍結，因為隨著項目的進展，預期會有添加/刪除/修改。

最後一點是最相關的一點。產品待辦事項的目的是成為活躍的需求來源。它不是在開始時創建的，而是保存在存儲位置。

相反，它意味著一次又一次地共享，因為變化不斷湧現。隨著進度的增加，可能會出現新的要求，這也可能會改變積壓項目的優先級。在某些情況下，新要求依賴於積壓中的另一個項目，因此可能需要重新調整項目優先級。

或者可能存在可能必須首先實施的關鍵用戶故事，因為客戶希望在其他人之前看到該故事，即使根據PO和Scrum團隊決定的因素，優先級可能不高。

因此，產品積壓是PO擁有的業務需求的有序列表，並隨著項目的進展一次又一次地訪問。

Sprint Backlog

您可能還記得scrum團隊在2到4週的短暫迭代中工作稱為sprint。在這些衝刺期間，Scrum團隊從PO創建的產品待辦事項中識別項目，他們計劃在下一次迭代中提供這些項目。Scrum團隊選擇使用的項目成為sprint backlog的一部分。

因此，他們決定在下一次產品迭代中將會有哪些功能。scrum團隊決定將什麼進入sprint backlog，因為他們正在開展工作。

因此，他們應該估計實施這些故事所涉及的工作並決定他們能夠提供多少。

該團隊不僅從產品積壓中選擇要處理的項目，而且還估計了他們開發該功能所需的時間。它們還通過創建實現sprint目標所需的詳細任務來添加高級用戶故事。

Scrum團隊還可以在sprint期間根據需要不斷更新sprint backlog，但只有scrum團隊才能對sprint backlog進行更改。

典型的Sprint Backlog將如下所示。

sprint board visual paradigm的圖片搜尋結果

理想情況下，團隊每天可以更新一次，scrum master可以使用此信息創建sprint burndown圖表。這個燃盡圖表將幫助團隊了解sprint還剩下多少工作，團隊可以相應地規劃他們的工作。如果需要，他們甚至可以添加或刪除任務。

創建sprint backlog時的一些最佳實踐可以是：

＃1）做出團隊決策 –不應該是scrum master或任何其他scrum團隊成員決定積壓。相反，它應該是整個團隊共同決定在sprint積壓中包含哪些項目以及如何規劃它們。

這個跨職能團隊的每個成員都有自己的技能，我們必須利用他們的經驗創造最好的積壓。

＃2）不分配任務 –由於在敏捷文獻中多次重複，因此不要將任務分配給團隊成員。一個scrum團隊應該是自給自足的，他們應該知道如何自己組織他們的工作。

因此，我們不應該分配工作，而是讓團隊自己選擇工作，並自己決定如何繼續工作。

＃3）已完成的定義 – 不僅應由利益相關方商定，而且每當他們必須就衝刺目標做出任何決定時，團隊都應清楚地看到所有點。這將提醒我們在交付可運送的可運輸產品之前需要做些什麼。

＃4）不斷更新積壓 –隨著sprint的發展，團隊必須獲得更多的理解，因此他們應該相應地更新sprint積壓以反映這種更好的理解。它不應該隨時成為靜態文檔。

＃5）添加任何任務 –任務不僅需要與編碼相關，而且可能必須提供可交付的產品。因此，在積壓中也提到了這樣的任務。

產品增量 (Product Increment)

scrum increment visual paradigm的圖片搜尋結果

這將我們帶到最後的Scrum工件，即產品增量。根據Scrum指南的定義，Increment是Sprint期間完成  的所有Product Backlog項目的總和，   以及所有先前Sprint的增量值。正如我們現在所知，Scrum是一個迭代過程。

每次迭代的結果都是此產品增量，每個此類產品增量都有助於團隊更接近於交付最終產品。

這意味著什麼是衝刺的結果是增量。顯然，為了將結果視為增量，它應該首先滿足預定義的完成定義，即最終結果應該是能夠“運輸”的可用產品。

它可以被檢查，使用和測試，以確保它確實按照定義“完成”，如果產品所有者希望，它也可以被釋放以便上線。

提供此產品增量最重要的是對所有人都理解的“完成定義”有共同的理解。

Scrum團隊永遠不應懷疑他們所做的事情是否會被接受。如果有任何疑問，完成的定義應該足夠完整，以指導他們如何進一步行動。僅基於此定義，Scrum團隊決定為sprint選擇多少產品待辦事項。

這是sprint預期的最小值。

Scrum  Artifact Articles

 

 

Leave a Reply

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