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

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

• 什么是Prodcut Backlog
  

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

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

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

Make the Product Backlog DEEP

• Prodcut Backlog有什么用?

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

• 誰提供product backlog的需求

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

• 什么時候會修改product backlog

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

• 怎么寫故事

一般按照輕量級的故事來進行描述需求。用戶故事是最基本的設計單元，它是從系統(tǒng)用戶或者客戶的角度出發(fā)對功能的一段簡要描述。用戶故事的形式很自由，沒有什么強制性的語法。但是，按照大致符合這樣一個形式來考慮 用戶故事是比較有益的：“作為【用戶的類型】，我希望可以【先這樣做，然后那樣做，就應該得到…的結果】以便【業(yè)務價值】?！币赃@樣的模作為例子，可以得到一個用戶故事說：“作為購書者，我希望可以根據(jù)ISBN來找到一本書，以便能更快的找到正確的書?！痹谧鲇脩艄适聲r，需要注意每個用戶故事用的是用戶的語言，它只描述一個功能（feature），而且每個用戶故事的開發(fā)周期不要太長（1－5天）

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

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

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

INVEST in Good Stories, and SMART Tasks

如何溝通故事

• 
  

總結

以上是生活随笔為你收集整理的Scrum 之 product Backlog的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。