开发管理 CheckLists(17) -敏捷开发 SCRUM评估会议

注： 开发管理 CheckLists-系列文章是从本人   Iteye博客中移植过来.后续会直接在此更新     开发管理 CheckLists   专栏

本文主要是为了检测你对SCRUM 评估会议的了解和使用程度,

通过本文你可以检测一下 
    1、你们的SCRUM 评估会议的过程和步骤
    2、SCRUM 评估的输出结果

一、会议目的 

     1.  确定 Backlog 中各项的大小.
     2.  确定团队在一个Sprint中能够完成多少工作。 
     3.  团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。 
     4.  修整Backlog内容：以合理方式分解Backlog各个项目，从而获得更深入的理解  

     基本要求： 
         只有团队才能作估算。Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。

二、会议时间 

       1. 该会议时间限制为不超过 90分钟。 
       2. 如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适  

三、会议准备 

       1. 邀请与会者：
             产品负责人
             Scrum Master
             团队所有成员  
       2. 已按优先级排列好产品 Backlog 中的各项问题 
       3. 把产品 Backlog 公开给所有人，保证其可被获取 
       4. 在用作计划纸牌的一组卡片上写上标签 1，2，3，5，8，13，21，34，89，并发到每个团队成员的手上  

四、会议进程 

    介绍会议的目标
       1. Product Owner展示她希望得到估算的 Product Backlog条目。 
       2. 团队使用规划扑克来估算Backlog条目。  
       3. 如果完全还没开始着手对 Backlog 中的问题进行评估：
           (1)、选择 Backlog 中您认为是最小用例的问题，并指派其工作量为 2 个 Story Point对于产品 Backlog 中的各项问题：
           (2)、由产品负责人来解释 Backlog 中该问题背后的详细用例。
           (3)、团队各成员选出其手上的一张计划卡片，以投票决定他所认为的该问题的工作量大小。
           (4)、所有团队成员同时亮出他们的卡片如果评估结果有分歧，让意见分歧最大的成员进行辩论，然后再次投票，直到所有人意见一致
           (5)、评估结果被添加到 Backlog 项  
 
       4. 如果某个 Backlog条目过大，需要放到下一个或是后续的 Sprint中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog条目使用规划扑克进行估算。 
       5. 重新估算 Backlog中当前没有完成、但是可能会在接下来三个Sprint中要完成的条目。
       6. 通过简洁的总结来结束评估会议
           (1)、如果有需要的话，再安排时间另开一个评估会议
       7.  区分出下一次估算会议需要澄清的Backlog条目。 
        
    
五、会议结果 

      1. 经过估算的Product Backlog。 
      2. 更小的Backlog条目。 
      3. 需要澄清的问题。   

      4. 公司的所有人员都要获得这个已经评估的backlog

        <开发管理 CheckLists> by dyllove98 @开发管理 CheckLists