回顧Day 7任務分配時，任務指派型的情境。

這樣的任務分配結果有以下缺點:

• Scrum 導師(SM) 處在開發 MVP 卡片的狀態，該卡片完成前，抽身處理突發狀況的時間有限。
• 實戰經驗較強的成員後端1，分配到相對簡單的卡片。
• 實戰經驗較弱的成員後端3，分配到 MVP 卡片。

假設此情境下，燃盡圖(Burndown Chart)的運作結果如下:

9/1 星期四活動開始。
9/2 星期五疊代追蹤報告(iteration review)發現『API介接取得資料』這張 MVP 卡片進度為0，Scrum 導師(SM)眉頭一皺，發現不對勁後，立馬將後端1改成處理『API介接取得資料』，後端3接手處理『協調資料結構』。
9/3-9/4 正常休假。
9/5 星期一完成了6張卡片，替換成員奏效。持續努力追上參考線的進度。
9/6 星期二衝刺完成4張卡片。
9/7 星期三穩定完成2張卡片後，沒有剩餘卡片，衝刺成功達標。

在衝刺活動(sprint)過半前，燃盡圖(Burndown Chart)中看到進度為0的水平線出現在工作日時，Scrum 導師(SM)應即早介入替換適當成員來處理造成滯礙的卡片。

基本上，所有成員每次的疊代追蹤報告(iteration review)中，卡片中都要列出檢查清單的這個好習慣。

以程式開發來說，遭遇問題時就如同Day 9所提到方式列出問題 ; 沒問題的話就列一下每日版控的commit流水號。

如何讓每次的疊代追蹤報告(iteration review)更有效率，是整個衝刺活動(sprint)能否達標的關鍵。

今天介紹即早發現成員能力不足，替換開發成員順利達標。明天來介紹下，為時已晚，無法替換成員的手段。