Scrum series | How we do product backlogs

2008-03-29 17:39:10

　标签：Scrum Porduct backlog　　　[推送到技术圈]

本文原文来自Scrum And Xp From The Trenches 一书，感兴趣者可以去Infoq.com寻找此书。

How we do product backlogs.

Product Backlog是Scrum的心脏，是一切的开始。它基本上是一个需求的优先级列表，也可以说是stories，features，无论哪个都可以，只要你明白这个意思，就是客户自己想要的用客户自己的话语描述出来的东东。

而我们把这些归为stories，有时也只是被叫做backlog items.

我们的stories包含以下内容：

ID －只是一个自动增长的唯一标识。这是为了避免在我们修改这些backlog items名字的时候丢失对它们的跟踪。
Name －一个对于Story简短的描述性文字。例如：“See your own transaction history ”. 它应该是足够清晰的，可以让开发团队和产品负责人明白它是指什么，并且可以和其他的stories区别开来。通常是2 － 10个单词。
Importance － story的重要级别。例如 10 或者 150，数字大的指代更加重要的级别。

“我一般倾向于避免使用‘priority’这样的词，因为 priority 1 是被公认的最高优先级，但是你之后决定的something也许更重要呢，你如何定义这个优先级呢？ priority 0 ? priority -1 ?”
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的一半时间）。
How to demo －这是对这个story在sprint demo里如何去演示的高级描述。本质来说，这是一个简单的测试规格：“先这样，然后再那样，你看。发生了什么？”

如果你用TDD，那么这些描述可能是你进行合理测试的伪代码。
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 ，主要是为了方便产品负责人来排列优先级。

Track － story的粗糙归类。例如 “back office” or “optimization”. 这样产品负责人就可以容易的把所有的 optimization过滤出来，把他们的优先级设低等等等的操作。
Components －通常在execl文档里用复选框来表示。例如 “database，server，client”。团队成员和产品负责人可以识别实现这个story的时候是和哪些技术组件相关的。当有多个scrum团队的时候这是非常有用的，例如一个back office团队和一个client团队，这样每个团队就可以更容易的去决定哪些stories可以去接受。
Requestor －产品负责人可能想了解哪个客户或利益相关者最初提出的这个tiem，以便在迭代中给他一些反馈。
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