延續昨日列出的任務指派型情境缺失:

假設此次燃盡圖(Burndown Chart)的運作結果如Day 10案例三:

現在，要做的就是在9/5發現『API介接取得資料』這張 MVP 卡片阻礙了其他卡片的開發時，除了換人之外還有什麼其他手段嗎 ?
由於實際的介接資料無法取得(Extract)，後續的資料轉換(Transform)及資料呈現(Load)自然無法進行下去。其中一項可能原因就是第三方的文件太多，一個人負荷不了。

如果是上面這種情況的話，Scrum 導師(SM)可以直接加派人手一起來處理。加派的人手，自然是以目前已經完成衝刺活動(sprint)的成員，例如: 接到爽缺的後端1。另外，單元測試(註)的部分也可以先暫停到第二期的衝刺活動(sprint)再一併測試。

如上圖9/5後端三已經反應文件太多看不完，因此同一張卡片增加兩個成員一起處理。然後就抱著必死的決心努力把這張 MVP 卡片給完成。
多人完成的卡片，可以參考下面的卡片樣式編輯。

然後就如同案例三的結果完成衝刺。

即便燃盡圖(Burndown Chart)的運作結果如Day 10案例四:

如果剩下的卡片非 MVP 卡片，仍是可以接受的落後。

簡單給個結論就是:

Scurm 導師(SM)可視實際進度，適當的擱置非 MVP 的卡片取得人力，務必在衝刺活動(sprint)期間完成所有 MVP 卡片。

明天再繼續來介紹這張落後的單元測試卡片，在進入第二期衝刺活動(sprint)時，有什麼事項該注意的吧。

註: 單元測試一般是依據AAA原則，對於撰寫好的程式進行測試。基本上功能越完整，測試的可信度越高。因此在這個案例中可被擱置。對於單元測試想進一步了解，可以參考[Day 9] 從道館功能解說UnitTest的重要性--by a Java Programmer。