Product Backlog 是Scrum的核心。
它就是一个需求、或故事、或特性等做成的列表，按照重要性的级别进行排序。里面包含客户想要的东西，并用客户术语描述出来。我们称作"故事"(Story)，有时也称作"Backlog 条目"。
"故事"包括如下字段：
ID：统一标示符，自增字段。防止"故事"重复。
Name(名称)：简短的、描述性的故事名称。它必须要含义明确，这样产品负责人和开发人员才能通过字面意思明白"故事"的含义。一般2~10个字。比如："查看个人交易明细"。
Importance(重要性)：产品负责人评出一个数值来衡量"故事"的重要性，数值越大，重要性越高。
Initial estimate(初始估算)：完成"故事"所需的工作量。最小单位"故事点"，一般大致相当于一个"理想的人天(man-day)"。附：【故事点】，就是把人锁到一个屋子里，有吃有喝，在完全没有打扰的情况下工作，需要几天才能给出一个经过测试验证，可以交付的完整的实现呢？如果答案是"3个人大概4天"，那么初始估算的值是12个故事点。
这个估算值不需要保证绝对无误，也不可能绝对的无误，而是要保证相对的正确性(即，两个点的故事所花费的实践应该是四个点的故事所花费的时间的一半)
How to Demo(如何做演示即，手顺)：简述这个故事应该如何在Sprint演示上进行示范，其实就是一个简单的测试规范。比如，先这样做，再那么做，然后做什么，最后就得到该得到的效果。
Notes(注解)：相关信息、解释说明、其他资料的引用等等，简短意赅。
通常Product Backlog这个文档应该归产品负责人所有，但我们一般不排斥其他用户，因为开发人员经常要打开这个文档，弄清楚一些事情，或是修改估算值。
疑问：迭代开始后，这个估算值可以被频繁修改吗 ？