Product Backlog源自于Scrum方法，是指產(chǎn)品待辦事項(xiàng)的集合，其中事務(wù)有優(yōu)先級(jí)判斷，先處理優(yōu)先級(jí)高的事項(xiàng)。那么，如何制定Product Backlog呢？

Product backlog是一個(gè)敏捷團(tuán)隊(duì)管理開發(fā)過(guò)程的核心，所有的活動(dòng)和交付物都圍繞Product backlog來(lái)進(jìn)行。在制定Product backlog的過(guò)程中會(huì)遇到很多問(wèn)題，接下來(lái)，我們將結(jié)合Worktile敏捷開發(fā)實(shí)例，帶大家一起學(xué)習(xí)如何制定Product backlog 。

一、Product backlog和用戶故事

Product backlog是Scrum的核心，也是一切的起源。它是由Product Owner負(fù)責(zé)制定的一個(gè)按照重要性的級(jí)別排序的用戶故事列表。

規(guī)模較小的用戶故事可以直接加入Product backlog；規(guī)模較大的用戶故事要先拆分，再加入Product backlog進(jìn)行迭代。

用戶故事是一句簡(jiǎn)短的、采用用戶熟悉的術(shù)語(yǔ)表達(dá)的需求，是Product owner講給開發(fā)人員的故事，含有一定業(yè)務(wù)價(jià)值的端到端交付。

用戶故事是描述對(duì)用戶有價(jià)值的功能，一個(gè)好的用戶故事應(yīng)該包括角色、功能和商業(yè)價(jià)值三個(gè)要素。

1. 角色：到底是誰(shuí)要使用這個(gè)功能，這個(gè)功能是為誰(shuí)而設(shè)計(jì)的？
2. 功能：這個(gè)功能是怎樣的，要達(dá)到什么程度？
3. 商業(yè)價(jià)值：為什么要這個(gè)功能，這個(gè)功能最后能帶來(lái)什么有益的商業(yè)價(jià)值，對(duì)用戶來(lái)說(shuō)有什么意義？

一般我們?cè)诿枋鲆粋€(gè)用戶故事的時(shí)候會(huì)按照以下格式：

作為一個(gè)<角色>, 我想要<功能>, 以便于<商業(yè)價(jià)值>。

比如：作為一個(gè)“項(xiàng)目經(jīng)理”，我想要“有快捷方法把所有項(xiàng)目生成甘特圖”，以便于“項(xiàng)目管理和查看所有項(xiàng)目進(jìn)度?！?/p>

需要注意的是用戶故事不能夠使用技術(shù)語(yǔ)言來(lái)描述，要使用用戶可以理解的業(yè)務(wù)語(yǔ)言來(lái)描述。在Worktile中，我們用一個(gè)任務(wù)類型為“敏捷需求”的任務(wù)代表一個(gè)用戶需求。

二、如何編寫Product backlog或用戶故事

Product backlog一般由Product owner編寫，再確定優(yōu)先級(jí)，最后在Sprint plan meeting上和開發(fā)團(tuán)隊(duì)確認(rèn)。但有時(shí)研發(fā)團(tuán)隊(duì)也會(huì)寫，比如：作為研發(fā)人員，我需要寫一個(gè)操作緩存的模塊，這就是研發(fā)initial的backlog。

用戶故事看似簡(jiǎn)單，但是其實(shí)是很難寫。比如：作為會(huì)議管理員，可以查看所有用戶的提問(wèn)，以便了解哪些用戶發(fā)表的評(píng)論。看上去這種價(jià)值描述不錯(cuò)，但是如果系統(tǒng)只是為了查看的話，會(huì)議管理員為什么要查看？如果評(píng)論很多，他如何查看？

所以用戶故事的價(jià)值描述其實(shí)是給需求分析做了一些價(jià)值挖掘的要求，團(tuán)隊(duì)要去挖掘角色做這一動(dòng)作的價(jià)值，并為角色挖掘出必要且合理的理由。

用戶故事具備以下六個(gè)特征：

1. 獨(dú)立性（Independent）：要盡量避免故事間的相互依賴。在對(duì)故事排列優(yōu)先級(jí)時(shí)，或者使用故事做計(jì)劃時(shí)，故事間的相互依賴會(huì)導(dǎo)致工作量估算變得更加困難。通?？梢酝ㄟ^(guò)兩種方法來(lái)減少依賴性：

1. 將相互依賴的故事合并成一個(gè)大的、獨(dú)立的故事；
2. 用一個(gè)不同的方式去分割故事。

2. 可討論性（Negotiable）：故事卡是功能的簡(jiǎn)短描述，細(xì)節(jié)將在客戶團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)的討論中產(chǎn)生。故事卡的作用是提醒開發(fā)人員和客戶進(jìn)行關(guān)于需求的對(duì)話，它并不是具體的需求本事。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié)，實(shí)際上限制了和用戶的溝通。

3. 對(duì)用戶或客戶有價(jià)值的（Valuable）：用戶故事應(yīng)該很清晰地體現(xiàn)對(duì)用戶或客戶的價(jià)值，最好的做法是讓客戶編寫故事。一旦一個(gè)客戶意識(shí)到這是一個(gè)用戶故事并不是一個(gè)合同，而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂(lè)意寫下故事。

4. 可估算的（Estimable）：開發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級(jí)，工作量，安排計(jì)劃。但是讓開發(fā)者難以估計(jì)故事的問(wèn)題來(lái)自：

①開發(fā)人員缺少領(lǐng)域知識(shí)；

②開發(fā)人員缺少技術(shù)知識(shí)；

③故事太大了。

5. 小的（Small）： 一個(gè)好的故事在工作量上要盡量小，最好不要超過(guò)10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代或Sprint中能夠完成。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。

6. 可測(cè)試的（Testable）：故事必須是可測(cè)試的。成功通過(guò)測(cè)試可以證明開發(fā)人員正確地實(shí)現(xiàn)了故事。如果一個(gè)用戶故事不能夠測(cè)試，那么你就無(wú)法知道它什么時(shí)候可以完成。一個(gè)不可測(cè)試的用戶故事例子：用戶必須覺(jué)得軟件很好用。

在很多項(xiàng)目中，Product owner只是從一個(gè)角度編寫Product backlog，這樣往往容易忽略很多需求。所以在編寫用戶故事前要識(shí)別用戶角色和虛擬人物(Personal)，從不同角度編寫Product backlog 。

以下是招聘網(wǎng)站可能出現(xiàn)的用戶角色列表：

三、如何確定Sprint backlog的優(yōu)先級(jí)

編寫完P(guān)roduct backlog后，Product Owner需要對(duì)需求進(jìn)行優(yōu)先級(jí)的評(píng)定，根據(jù)優(yōu)先級(jí)從高到低依次作為Sprintbacklog。評(píng)定標(biāo)準(zhǔn)由Product Owner定。

對(duì)于一些無(wú)法估算時(shí)間成本的backlog，需要細(xì)化到一個(gè)能估算的backlog為止。

例如，此次的backlog是A功能，但要做A功能的時(shí)間無(wú)法估算，拆分A功能發(fā)現(xiàn)要做A需要先做B功能，可要做B功能的時(shí)間也無(wú)法估算，再拆分B功能發(fā)現(xiàn)要先做C功能，而C功能可以估算。這時(shí)的Backlog優(yōu)先級(jí)就是C→B→A。

需要注意的是，Sprintbacklog在項(xiàng)目進(jìn)展過(guò)程中是會(huì)發(fā)生變化的，只有Product owner有權(quán)來(lái)修改優(yōu)先級(jí)。

四、Worktile是如何管理Product backlog的

Worktile支持自定義任務(wù)類型，這表示客戶可以根據(jù)自己的需求，靈活配置任務(wù)的狀態(tài)／屬性信息，以及任務(wù)的工作流以及關(guān)聯(lián)關(guān)系等。Worktile中用一系列的標(biāo)簽來(lái)區(qū)分用戶故事的信息，需求來(lái)源對(duì)應(yīng)角色，任務(wù)名稱對(duì)應(yīng)功能，還可以自定義規(guī)模、優(yōu)先級(jí)等。

Worktile對(duì)Product backlog的管理，是按照以下幾個(gè)步驟進(jìn)行的：

1. 通過(guò)收集社區(qū)、幫助中心、后臺(tái)的客戶反饋，由客戶成功整理出自客戶／產(chǎn)品／售后等渠道的用戶故事，由產(chǎn)品負(fù)責(zé)人細(xì)化為需求；
2. 在Worktile中建立項(xiàng)目和需求任務(wù)；
3. Pruduct owner整理需求池；
4. 安排研發(fā)優(yōu)先級(jí)；
5. 在Sprint plan meeting上Scrum團(tuán)隊(duì)溝通，給開發(fā)團(tuán)隊(duì)分配任務(wù)。

當(dāng)開發(fā)團(tuán)隊(duì)完成了Product backlog并不是就真正的結(jié)束了，還需要驗(yàn)收，或者叫用戶故事的測(cè)試要點(diǎn)，驗(yàn)收標(biāo)準(zhǔn)由Product owner自己決定或是在Sprint Review Meeting和開發(fā)團(tuán)隊(duì)一起決定，每個(gè)團(tuán)隊(duì)的驗(yàn)收標(biāo)準(zhǔn)都不一樣，有些團(tuán)隊(duì)以需求完成作為驗(yàn)收標(biāo)準(zhǔn)，有些團(tuán)隊(duì)以需求通過(guò)測(cè)試為驗(yàn)收標(biāo)準(zhǔn)，但總體的驗(yàn)收標(biāo)準(zhǔn)遵循DoD（Definition of Done）原則。

綜上，一個(gè)完整的Product backlog = 用戶故事+ 優(yōu)先級(jí) + 驗(yàn)收標(biāo)準(zhǔn)。

#專欄作家#

袁林，人人都是產(chǎn)品經(jīng)理專欄作家。分享SaaS運(yùn)營(yíng)和企業(yè)管理／協(xié)作／辦公的相關(guān)知識(shí)

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于 CC0 協(xié)議