開發管理 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