Product Backlog源自於Scrum方法，是指產品待辦事項的集合，其中事務有優先級判斷，先處理優先級高的事項。那麼，如何制定Product Backlog呢？
Product backlog是一個敏捷團隊管理開發過程的核心，所有的活動和交付物都圍繞Product backlog來進行。在制定Product backlog的過程中會遇到很多問題，接下來，我們將結合Worktile敏捷開發實例，帶大家一起學習如何制定Product backlog 。
一、Product backlog和用戶故事
Product backlog是Scrum的核心，也是一切的起源。它是由Product Owner負責制定的一個按照重要性的級別排序的用戶故事列表。
規模較小的用戶故事可以直接加入Product backlog；規模較大的用戶故事要先拆分，再加入Product backlog進行迭代。
用戶故事是一句簡短的、採用用戶熟悉的術語表達的需求，是Product owner講給開發人員的故事，含有一定業務價值的端到端交付。
用戶故事是描述對用戶有價值的功能，一個好的用戶故事應該包括角色、功能和商業價值三個要素。
角色：到底是誰要使用這個功能，這個功能是為誰而設計的？功能：這個功能是怎樣的，要達到什麼程度？商業價值：為什麼要這個功能，這個功能最後能帶來什麼有益的商業價值，對用戶來說有什麼意義？一般我們在描述一個用戶故事的時候會按照以下格式：
作為一個<角色>, 我想要<功能>, 以便於<商業價值>。
比如：作為一個「項目經理」，我想要「有快捷方法把所有項目生成甘特圖」，以便於「項目管理和查看所有項目進度。」
需要注意的是用戶故事不能夠使用技術語言來描述，要使用用戶可以理解的業務語言來描述。在Worktile中，我們用一個任務類型為「敏捷需求」的任務代表一個用戶需求。
二、如何編寫Product backlog或用戶故事
Product backlog一般由Product owner編寫，再確定優先級，最後在Sprint plan meeting上和開發團隊確認。但有時研發團隊也會寫，比如：作為研發人員，我需要寫一個操作緩存的模塊，這就是研發initial的backlog。
用戶故事看似簡單，但是其實是很難寫。比如：作為會議管理員，可以查看所有用戶的提問，以便了解哪些用戶發表的評論。看上去這種價值描述不錯，但是如果系統只是為了查看的話，會議管理員為什麼要查看？如果評論很多，他如何查看？
所以用戶故事的價值描述其實是給需求分析做了一些價值挖掘的要求，團隊要去挖掘角色做這一動作的價值，並為角色挖掘出必要且合理的理由。
用戶故事具備以下六個特徵：
1. 獨立性（Independent）：要儘量避免故事間的相互依賴。在對故事排列優先級時，或者使用故事做計劃時，故事間的相互依賴會導致工作量估算變得更加困難。通常可以通過兩種方法來減少依賴性：
將相互依賴的故事合併成一個大的、獨立的故事；用一個不同的方式去分割故事。2. 可討論性（Negotiable）：故事卡是功能的簡短描述，細節將在客戶團隊和開發團隊的討論中產生。故事卡的作用是提醒開發人員和客戶進行關於需求的對話，它並不是具體的需求本事。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。
3. 對用戶或客戶有價值的（Valuable）：用戶故事應該很清晰地體現對用戶或客戶的價值，最好的做法是讓客戶編寫故事。一旦一個客戶意識到這是一個用戶故事並不是一個合同，而且可以進行協商的時候，他們將非常樂意寫下故事。
4. 可估算的（Estimable）：開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：
①開發人員缺少領域知識；
②開發人員缺少技術知識；
③故事太大了。
5. 小的（Small）： 一個好的故事在工作量上要儘量小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。
6. 可測試的（Testable）：故事必須是可測試的。成功通過測試可以證明開發人員正確地實現了故事。如果一個用戶故事不能夠測試，那麼你就無法知道它什麼時候可以完成。一個不可測試的用戶故事例子：用戶必須覺得軟體很好用。
在很多項目中，Product owner只是從一個角度編寫Product backlog，這樣往往容易忽略很多需求。所以在編寫用戶故事前要識別用戶角色和虛擬人物(Personal)，從不同角度編寫Product backlog 。
以下是招聘網站可能出現的用戶角色列表：
三、如何確定Sprint backlog的優先級
編寫完Product backlog後，Product Owner需要對需求進行優先級的評定，根據優先級從高到低依次作為Sprintbacklog。評定標準由Product Owner定。
對於一些無法估算時間成本的backlog，需要細化到一個能估算的backlog為止。
例如，此次的backlog是A功能，但要做A功能的時間無法估算，拆分A功能發現要做A需要先做B功能，可要做B功能的時間也無法估算，再拆分B功能發現要先做C功能，而C功能可以估算。這時的Backlog優先級就是C→B→A。
需要注意的是，Sprintbacklog在項目進展過程中是會發生變化的，只有Product owner有權來修改優先級。
四、Worktile是如何管理Product backlog的
Worktile支持自定義任務類型，這表示客戶可以根據自己的需求，靈活配置任務的狀態／屬性信息，以及任務的工作流以及關聯關係等。Worktile中用一系列的標籤來區分用戶故事的信息，需求來源對應角色，任務名稱對應功能，還可以自定義規模、優先級等。
Worktile對Product backlog的管理，是按照以下幾個步驟進行的：
通過收集社區、幫助中心、後臺的客戶反饋，由客戶成功整理出自客戶／產品／售後等渠道的用戶故事，由產品負責人細化為需求；在Worktile中建立項目和需求任務；Pruduct owner整理需求池；安排研發優先級；在Sprint plan meeting上Scrum團隊溝通，給開發團隊分配任務。當開發團隊完成了Product backlog並不是就真正的結束了，還需要驗收，或者叫用戶故事的測試要點，驗收標準由Product owner自己決定或是在Sprint Review Meeting和開發團隊一起決定，每個團隊的驗收標準都不一樣，有些團隊以需求完成作為驗收標準，有些團隊以需求通過測試為驗收標準，但總體的驗收標準遵循DoD（Definition of Done）原則。
綜上，一個完整的Product backlog = 用戶故事+ 優先級 + 驗收標準。
#專欄作家#
袁林，人人都是產品經理專欄作家。分享SaaS運營和企業管理／協作／辦公的相關知識
本文原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於 CC0 協議