国内项目的Scrum实践- 怎么做PB（product backlog）

国内项目的Scrum实践-- 如何做PB（product backlog）
今天总结一下这几天如何做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。这里仅是把前期没有记录的所有功能做一个总括而已,历史原因-:)。