Scrum series | How we do product backlogs

本文原文来自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