产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求或故事或特性等组成的列表，按照重要程度进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。
我们称之为“故事”（story），有时候也称之为“backlog条目”（事项）。
我们的故事包括这样一些字段。
ID 统一标识符，就是一个自增长的数字而已，以防重命名故事以后找不到。
Name（名称），简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
Importance（重要性），产品负责人估出一个数值 ，指出这个故事有多重要。例如10或150。分数越高，表明越重要。
我一直都想避免“优先级”这个说法，因为一般说来优先级1都表示最高优先级，如果后来有其他更重要的东西，岂不麻烦了？它的优先级评级应该是什么呢？优先级0？优先级-1？
Initial estimate（初始估算）团队的初步估算，表示与其他故事相比，完成该故事所需要的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想人天”（man-day）。
问一下团队：“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下闭关工作，需要几天才能给出一个经过测试验证、可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。
不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即两个点的故事所花费的时间应该是四个点的故事所需的
一半）。
How to demo（如何做演示）它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果。”
如果在使用TDD（测试驱动开发），这段描述就可以作为验收测试的伪码表示。
Notes（注解）相关信息、解释说明和对其他资料的引用等。一般都非常简短。
