例如，我们建立一个产品 BACKLOG(示例)，如表1所示。

表1 产品 BACKLOG(示例)

我们的故事包括这样一些字段：

ID：统一标识符，就是个自增长的数字而已，以防重命名故事以后找不到它们。

名称(Name)：简短的、描述性的故事名。它必须要含义明确，这样可以跟其他故事区分开。

重要性：(Importance)：产品负责人评出一个数值，指示这个故事有多重要。例如：

20或100。分数越高越重要。避免“优先级”这个说法，因为一般说来优先级1都表示“最高”优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢?优先级0?优先级-1?

初始估算(Initial estimate)：团队的初步估算，表示与其他故事相比，

完成该故事所需的工作量。最小的单位是故事点(story point)，一般大致相当于一个“理想的人天(man-day)”。

如何做演示(How to demo)：它大略描述了这个故事应该如何在sprint 演示上进行规范，本质就是一个简单的测试规范。

笔者借鉴过很多敏捷书籍和在实战的应用中尝试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去，这也就是一种最简化。

我们可以把backlog存放在TFS2010服务器上，或者共享在TFS2010的Excel或者Project(参考图3所示)文档里面，这是为了多个用户可以同时编辑它。

图3 在TFS2010中的Project Product Backlog模板

虽然正规意义上这个文档应该归产品负责人所有，但是我们并不想把其他用户排斥在外，开发人员常常要打开这个文档，弄清一些事情，或者修改估算值。

VSTS2010已经支持Scrum的Product Backlog的模板，并且可以进行Backlog的迭代，如下图4所示。

图4 Product Backlog模板

打开Product Backlog，建立User Story，如图5所示。

图5 建立User Story图5 建立User Story

编写相关Story条目内容，如图6所示。

图6 编辑Story条目