介绍了上面三个Backlog的重要性，大家应该能感觉到在敏捷中，Backlog的确是非常重要的一个概念。下面就来具体介绍一下Backlog的几个分类：
由于不同的公司、不同的专家对Backlog的分类总是有点区别，所以我们就以业界最知名的敏捷开发工具 TechExcel DevSuite中的Backlog来举例子吧，
在DevSuite中， 你可以自定义把Backlog被分成几类， 如果按照最大分法的话，我们可以分成三类，一类叫做Product Backlog，第二类称为Release Backlog，最后一类名为Sprint Backlog，当然很多其它主流的分类只有第一种和第三种的分类，不过由于DevSuite这个是可以自定义让你自己根据实际需要启用几类的，所以今天还是以DevSuite的方式为准。
对于这三类分法，下面来解释一下：
1. Product Backlog (产品待办事项)是条目化/量化的用户需求，它将需求文档中需要实际开发的需求条目化地表达出来。
在这个Backlog里，存放着所有已经设计完成需要完成的用户需求，当然只是需要完成，不需要指定时间与负责人，只要分门别类就行了，未来会通过产品地不同版本来一一去实现，就像微软的Windows系列那样，也许微软早就已经设计好Windows 2020的功能了，只是现在还不去开发，只是先放在Product Backlog里罢了。
另外，这个Backlog还可以保存之前准备做但是又被取消或者延迟的一些用户需求等等。
2. Release Backlog是本次发布需要完成的任务
这里所谓的Release，是指一次大的发布，比如说微软的Windows 8发布。每次发布，我们必然有大量任务需要去完成，而这些任务，即使在敏捷中，也是会事先选择好这次发布需要完成哪些的，当然中间有变更，敏捷还是很欢迎的，但是我相信大部分应该没啥变化。
所以Release Backlog就保存了所有这个发布需要完成的工作，所以这个就意义重大。而且跟分配任务相关的估值、优先级的设置也是在这个地方完成的。
3. Sprint Backlog是本次迭代需要完成的任务
Sprint Backlog是开发过程用得最多的Backlog，因为每次Release会建立大量的Sprint，而每个Sprint都有一个Sprint Backlog。
在Release Backlog中已经设置好了Story的优先级与故事点数，所以根据这两个的值，我们就会通过分解生成更多小的任务的方式去分配到当前Sprint中去完成，开发组长只需要在Sprint Backlog中将任务根据员工的技术水平与可用时间进行合理分配就行了。
当分配的小任务无法在当前Sprint中完成的时候，可以根据需要在下个Sprint分配任务时分配到该Sprint中继续完成，当然估值方面就需要下次注意调整了。
本次Backlog浅析讲座就此完成，希望大家各抒己见，共同探讨，谢谢。
联系客服
