今天总结一下这几天如何做Product
Backlog
1. 和业务部门的PO讨论需求，以前没有功能的详细记录，从现在开始记录为Product Backlog：
1.1 未完成的功能：包括：
FTP服务器双机备份
新页面整合。新页面由外包公司制作，需要外包公司的配合
Bugs修改。由于没有Delicated QA，虽然相关人员做一些简单测试，也发现了不少的Bug，但还是需要核心的测试用例来Cover核心需求，保证测试质量
1.2 PO从客户那里得到了一些新的需求，包括
新增5个报表，
新增7个统计分析，
修改3个角色登陆首页，
新增几个角色分类
2. 优先级分类
2.1 PO的角度->Business Value的优先级：
优先级的分类：必须完成（300~399)，应该完成（200~299)，可能完成（100~199)，可能完不成（1~99)。数字越大，优先级越高。
已有功能的完成，包括页面整合，没有Bugs（350)
新增3个角色登陆首页，（350)
新增7个统计分析，（330)
新增几个角色分类 （330)
新增5个报表，(300)
FTP服务器双机备份 （250)
2.2 Team的角度->Technical
工作量估算标准：以没有任何干扰的情况下做完这个功能需要的人天（IDM，Ideal Man Day）。如果需求不明确，或者没有技术解决方案，可以估算为40以上的IDM），这样的需求功能需要细化、拆分或者作技术探求后在进行工作量估算。也可以用Story
Points来进行评估，但初期以IDM更容易应用。
工作量分析结果：
已有功能的完成，包括页面整合，功能性Bugs（没有测试用例，不能分析出具体有多少的Bugs，但需要完成）
已有功能UI级的Bugs（没有统一标准，无法明确工作量，估算为40IMD）
新增的报表，没有复杂报表实现和导出为Excel、PDF的技术方案，估算为40IMD
新增3个角色登陆首页，7IDM
新增7个统计分析,5IDM
新增几个角色分类，认为需求不明确，估算为40IMD
FTP服务器双机备份，5IDM， Team认为必须完成这个功能才能保证系统上线后的统计功能可靠性
3. PB细化及优先级重新分类
根据Business Value和Technical的分析，和PO讨论后Product Backlog的优先级为：
已有功能的完成，包括页面整合，没有功能性Bugs（350)
新增3个角色登陆首页，（350)
FTP服务器双机备份 （330)
新增7个统计分析，（330)
新增几个角色分类 （330)
复杂报表实现和导出为Excel、PDF的技术方案Spike（330)
新增5个报表，(300)
已有功能的完成，包括页面整合，没有UI级Bugs（250)
说明：“已有功能的完成，包括页面整合”，这本身并不是一个很好的PB内容，更好的是User Story，或者仅有核心内容的User
Case。这里仅是把前期没有记录的所有功能做一个总括而已,历史原因-:)。 | 
