Scrum工件:產品Backlog,Sprint Backlog和產品增量

Scrum工件

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

您的电子邮箱地址不会被公开。