本文原文來自Scrum And Xp From
The Trenches 一書，感興趣者可以去Infoq.com尋找此書。

How we do product backlogs.
Product
Backlog是Scrum的心臟，是一切的開始。它基本上是一個需求的優先順序列表，也可以說是stories，features，無論哪個都可以，只要你明白這個意思，就是客戶自己想要的用客戶自己的話語描述出來的東東。
而我們把這些歸為stories，有時也只是被叫做backlog
items.
我們的stories包含以下內容：
  1. ID －
    只是一個自動增長的唯一標識。這是為了避免在我們修改這些    backlog
    items名字 的時候丟失對它們的跟蹤。
  2. Name －
    一個對於    Story簡短的描述性文字。例如：“See
    your own transaction history
    ”.
    它應該是足夠清晰的，可以讓開發團隊和產品負責人明白它是指什麼，並且可以和其他的stories區別開來。通常是2
    － 10個單詞。
  3. Importance －
    story的重要級別。例如 10
    或者 150，
    數字大的指代更加重要的級別。
    “我一般傾向於避免使用‘priority’這樣的詞，因為
    priority 1 是被公認的最高優先順序，但是你之後決定的something也許
    更重要呢，你如何定義這個優先順序呢？     priority
    0 ? priority -1 ?”
  4. Initial estimate －
    這是團隊對實現一個    sotry相比於其他stories的工作量的估算。
    The unit is story points and
    usually corresponds roughly to “ideal
    man-days” （這有個概念是story
    points。）
    1）
    問團隊這個問題：如果你帶領最適合的人做這個    story（不太多也不太少，典型的是2個），並且把你們鎖到一個房間裡，給你們提供吃不完的食物和絕對安靜的工作環境，你們可以多長時間可釋出一個可交付的（
    finished, demonstratable,
    tested, releasable
    ）實現？
    如果團隊的答案是 “    3
    個人鎖到屋子裡大約需要4天”，這樣這個預估值就是12個story
    points。
    2）
    重要的是，不是絕對的預估值（例如，    2－point
    就應該是2天），而是相對的預估值（例如，2－point
    story 大約需要4－point
    story的一半時間）。
  5. How to demo －
    這是對這個    story在sprint
    demo裡如何去演示的高階描述。本質來說，這是一個簡單的測試規格：“先這樣，然後再那樣，你看。發生了什麼
    ？”
    如果你用TDD，那麼這些描述可能是你進行合理測試的虛擬碼。
  6. Notes －
    通常是一些簡單的摘要或者參考。
PRODUCT BACKLOG (example)
ID       Name        Imp      
Est         How to demo             
Notes
1         Deposit      30         
5           Log in, open deposit      
Need a UML
                                                        page, deposit €10,        
sequence
                                                        go to my balance          
diagram. No
                                                        page and check that     
need to worry
                                                        it has increased by        
about
                                                        €10.                              

encryption for

                                                                                              now.
2         See your     10         
8           Log in, click on             
Use paging to
           own                                      
“transactions”. Do a       avoid large
           transaction                           

deposit. Go back to       
DB queries.

           history                                  transactions, check       
Design
                                                        that the new deposit      
similar to
                                                        shows up.                      
view users
page.
上面這六項是我們經過多次實踐以後總結出來的。實際上，也只有這六項內容經常在sprint
被用到。
(省略一些廢話
。。。這product
backlog應該是被共享的可見的，不應該只是產品負責人擁有的，不應該遮蔽團隊成員的寫許可權)
Additional Story Fields
有時我們會在product
backlo裡用到其他fields
，主要是為了方便產品負責人來排列優先順序。
  1. Track －
    story的粗糙歸類。 例如
    “    back
    office” or “optimization”.
    這樣產品負責人就可以容易的把所有的
    optimization過濾出來，把他們的優先順序設低等等等的操作。
  2. Components －
    通常在    execl文件裡用核取方塊來表示。例如
    “    database，server，client”。團隊成員和產品負責人可以識別實現這個story的時候是和哪些技術元件相關的。當有多個scrum團隊的時候這是非常有用的，例如一個back
    office團隊和一個client團隊，這樣每個團隊就可以更容易的去決定哪些stories可以去接受。
  3. Requestor －
    產品負責人可能想了解哪個客戶或利益相關者最初提出的這個    tiem，以便在迭代中給他一些反饋。
  4. Bug Tracking
    ID － 如果你有一個獨立的bug跟蹤系統，類似於我們用的Jira，
    有助於瞭解這一陀一陀的    bugs reports 是對應於哪個story的。
How we keep the product backlog at
a business level
如果這個產品負責人有技術背景的話，他可能增加一些stories
，
就像這樣：Add indexes to the
Events table 。
 但是為什麼他想這麼做
？ 這個story真正的目標可能是這樣
“ speed up the
search event
form in the back office
” 。
 可能索引並不是導致查錶速度慢的瓶頸，也可能完全是另一回事。
團隊成員的角色更適合去指出：如何解決這些問題，而不是產品負責人的個人經驗判斷。
產品負責人應該聚焦在業務目標，而非技術上。

      當我看到這樣的技術

stories的時候，我通常會問這個產品負責人一系列的“..但是…為什麼…?(but
why)” 的問題，直到我從他嘴裡找到最終業務需求目標。然後我把這個story修改為“speed
up the
search event form in the back office
”，而最初的那條技術性story就可以作為一個Note
（“給eent table增加索引有可能解決這個問題”）

下集預告： How we prepare for sprint planning