Scrum 之 product Backlog

Scrum的基本概念其實並不複雜，但是想做好並不容易，大家都知道product backlog的重要性，但是我們如何制定和展現它，如何評定優先級，如何進行初始評估？下面我將介紹和product backlog相關的一些問題。

在Scrum之 流程和術語介紹了流程，這裏主要介紹第一個最重要的工件 Product Backlog。它是Scrum的核心，也是一切的起源。它是由Product Owner負責制定的一個按照重要性的級別排序了的故事列表。

 

• 什麼是Prodcut Backlog
  

 backlog英文意思爲“積壓的工作”。 product backlog是一個具有優先級的需求列表， 並對每個需求進行了粗略的估算。在Scrum中表示可以預知的所有任務，包括未細化的產品功能要求、Bugs、缺陷、用戶提出的改進、具競爭力的功能及技術升級等，按優先級定義出來，這些任務可能不是完整的，甚至可能隨時會更改或添加。Prodcut Backlog永遠處於不完整狀態，它隨着產品及其使用環境的變化而變化，它是動態的，管理層不斷對之做出改變，確定產品需求，保證產品適用性、實用性和競爭性。

 

 

1. 在列表上層的故事首先被團隊完成
2. Product Backlog不是制定一次就完了的，它是動態的，需要持續的被修訂，可能會出現故事的增加、刪除和修改、合併或者拆分
3. 任何一個Backlog的目標都是：它應該足夠短、級別足夠高，無特殊情況不需要修改。如果Backlog改變了，那麼我認爲你應該假設你的 Backlog錯了，而不是需求變更了。變更需求通常意味着Backlog太長或者太詳細，比如把複雜算法和邏輯也寫入了backlog中了，要不就是寫 的太含糊不清了，需要花費太多的時間猜測它究竟講的是什麼。

這裏有一個別人做的，大家可以參考一下 product sprint示例

Make the Product Backlog DEEP

• Prodcut Backlog有什麼用

 

產品backlog根據用戶價值羅列所有即將在產品中開發的功能，通過簡潔的展示需要實現的功能，我們可以對項目進行規模上的估算，確定發佈計劃和迭代計劃。產品backlog可以幫助我們對將要做的事情有個整體的認識，以及可以知道我們現在的狀態。如果沒有backlog，我們將不知道現在和將來產品做成什麼樣子，由於對產品目標的不明確，當然也不知道什麼時候可以發佈產品，或者發佈的產品能給客戶帶來什麼價值。

• 誰提供product backlog的需求

產品負責人與客戶最近，他最清楚產品應該做什麼樣子，所以product backlog應該由Product Owner來制定。裏面的需求由產品負責人或者客戶制定，有時候Team裏的需求分析人員可以和產品負責人或客戶一起定義需求。制定後，由Scrum master和Team協助產品負責人修訂並進行初始評估，裏面的需求在sprint計劃會議將進行更進一步的討論。

• 什麼時候會修改product backlog

 

如果一個列表太長或者內容陳舊，product backlog的浪費遠大於價值本身，所以我們必須不斷的維護產品backlog。產品backlog由產品負責人提供，與Team進行規模估算時，可能會拆分合並或者添加刪除故事，初始估計也由Team進行評估提供估計值。產品所有者通常會向開發小組提出自己確定的優先級順序，而小組也可能會請產品所有者根據他們對主題的評估對這個順序作出少量調整。

• 怎麼寫故事

 一般按照輕量級的故事來進行描述需求。用戶故事是最基本的設計單元，它是從系統用戶或者客戶的角度出發對功能的一段簡要描述。用戶故事的形式很自由，沒有什麼強制性的語法。但是，按照大致符合這樣一個形式來考慮 用戶故事是比較有益的：“作爲【用戶的類型】，我希望可以【先這樣做，然後那樣做，就應該得到...的結果】以便【業務價值】。”以這樣的模作爲例子，可以得到一個用戶故事說：“作爲購書者，我希望可以根據ISBN來找到一本書，以便能更快的找到正確的書。”在做用戶故事時，需要注意每個用戶故事用的是用戶的語言，它只描述一個功能（feature），而且每個用戶故事的開發週期不要太長（1－5天）

 我們不需要一開始對所有的故事都進行詳細的描述，但計劃放在下一個sprint中的故事應該比較清楚。可以按照硝煙一書中的表格來寫backlog的故事：

 

ID爲一個唯一標識，確定後最好固定不變，在其他工作或者文檔中想引用故事就使用這個ID來引用
Name2到10個字，通過簡單的描述來說明故事，如果要很多字才能表達這個故事，那很有可能這個故事太大，或者不清楚
重要性 這個優先級決定了sprint選擇的故事，優先級越高的越早實現
初始估算 這個由Team來根據故事描述內容來估算，產品負責人講解完故事後，Team對不清楚的進行詢問，大概瞭解後進行粗略估算。從估算的角度出發，故事不應該太短，但也不能太過於詳細，不需要把具體的規則和算法寫進去。
How do demo 從用戶視角，從操作層面進行講解這個故事如何通過軟件來演示，也可以作爲一個簡單的測試用例了。重要性高的backlog條目都要填寫”如何演示“。
Notes相關信息、解釋說明和對其他資料的引用等，一般都非常簡短。

有時我還會增加一個分類列來標識出故事的主題，通過主題來從更大視角來查看需求主要內容，後期也可以根據主題的優先級來初始確定故事的優先級。

INVEST in Good Stories, and SMART Tasks

• 如何溝通故事
  
  
• 怎麼拆分故事

• 怎麼評定優先級

• 怎麼進行初始評估