如何編寫產品backlog
產品 backlog 是 Scrum 的核心，也是一切的起源。從根本上說，它
就是一個需求、或故事、或特性等組成的列表，按照重要性的級別
進行了排序。它裏面包含的是客戶想要的東西，並用客戶的術語加
以描述。
backlog一般包含這幾個字段
- ID-----統一標識符，一個自增長數字
- Name ----- 簡短的描述性故事名
- Importance-----重要性
- Inisital estimate ---- 團隊初步估算工程量（包括story point ，一般大致相當於一個“理想的人天----man day”）
- How to demo -----它大略描述了這個故事應
該如何在 sprint 演示上進行示範，本質就是一個簡單的測
試規範。“先這樣做，然後那樣做，就應該得到……的結
果 ”。
o 如果你在使用 TDD（測試驅動開發），那麼這段
描述就可以作爲驗收測試的僞碼錶示。 - Notes — 相關信息、解釋說明和對其它資料的引
用等等。一般都非常簡短。
![在這裏插入圖片描述]()
額外的故事字段
有時爲了便於產品負責人判斷優先級別，我們也會在產品 backlog
中使用一些其它字段。
ƒ Track（類別）——當前故事的大致分類，例如“後臺系統”
或“優化”。這樣產品負責人就可以很容易選出所有的“優
化”條目，把它們的級別都設得比較低。類似的操作執行
起來都很方便。
ƒ Components（組件）——通常在 Excel 文檔中用“複選框”
實現，例如“數據庫，服務器，客戶端”。團隊或者產品
負責人可以在這裏進行標識，以明確哪些技術組件在這個
故事的實現中會被包含進來。這種做法在多個 Scrum 團隊
協作的時候很有用——比如一個後臺系統團隊和一個客戶
端團隊——他們很容易知道自己應當對哪些故事負責。
ƒ Requestor（請求者）——產品負責人可能需要記錄是哪個
客戶或相關干係人最先提出了這項需求，在後續開發過程
中向他提供反饋。
ƒ Bug tracking ID（Bug 跟蹤 ID）——如果你有個 bug 跟蹤
系統，就像我們用的 Jira 一樣，那麼瞭解一下故事與 bug
之間的直接聯繫就會對你很有幫助。
