Scrum 系列：Sprint 結束後，還沒完成的 PBI 應該怎麼處理？
在 Scrum 框架中，Product Backlog Item (PBI) 是待完成的工作項目。團隊在 Sprint 開始的時候舉辦 Sprint Planning 會議，選取合理數量的 PBI 放入 Sprint Backlog 中。團隊在 Sprint 結束的時候，會盡全力完成這些已選取的 PBI。
有一天，一位朋友私訊我：「Current Sprint 內未完成的 PBI，會挪到下一個 Sprint，對吧？」
我回答：「以結果來說，的確大部分的團隊選擇把未完成的 PBI，直接搬到下一個 Sprint。」
這個問題表面上看似簡單，背後其實有一個思考的脈絡。以下是兩個主要的處理方法：
1. 放回 Product Backlog
當未完成 PBI 的優先序降低，或是有依賴性需要等其他團隊時，可以將 PBI 放回 Product Backlog 中適當的位置，成為 Future Sprint 的候選項目。這樣，團隊在未來的 Sprint Planning 時，可以重新評估、安排和選取這些項目。
2. 移動到 Next Sprint
經過審慎評估後，判斷未完成的 PBI 應該在 Next Sprint 中繼續進行時，可以將 PBI 移動到 Next Sprint。
通常，大家就會接著問這一題：「那我們應該要把整個 PBI 移動到 Next Sprint，還是把 PBI 拆成兩個項目，已完成的項目保留在 Current Sprint，未完成的項目保留在 Next Sprint 呢？」
在回答這個問題之前，我們需要從價值的角度來思考。
假設有一張未完成的 PBI，它的點數為 8。如果 PBI 已經是最小的工作單元，無法繼續拆分帶給使用者價值，那這個 PBI 不應該被拆分。
如果此 PBI 完成的部分是可以獨立交付帶給使用者價值，那我們可以把 PBI 拆解成兩個 PBI，例如，第一個是完成的 PBI 點數為 3，第二個是未完成的 PBI，點數為 5。
實務上即使你這麼做，還是會遇到問題的，最常見的問題是未完成的 PBI 點數為 8，它也是最小的工作單元，繼續做拆解也無法帶給使用者價值。如果我們遵守規則把整個 PBI 移動到下個 Sprint，計算選取此 PBI 的團隊成員身上所有的 PBI 大小加總在一起，會發現些許澎風的成分。
另外，有些團隊會追蹤 Velocity Chart，如果把點數 8 的 PBI 完整認列到 Next Sprit 的完成點數，對於長期的 Average Velocity 是沒有影響的。但是當我們關注到每個 Sprint 的產出時，就會發現 Current Sprint 比較低，因為沒有計算到已完成部分的點數，Next Sprint 會比較高，因為一次認列了全部的點數。
綜合理論和實務以後，我自己的準則是這樣的：當 PBI 點數在 5 以下時，直接把 PBI 往 Next Sprint 移動，減少拆兩張單子的作業時間；當點數在 5 以上時，可以將 PBI 拆解成兩張，分配合適的點數給它們，完成的項目放在 Current Sprint，未完成的項目放在 Next Sprint。
在 Azure DevOps 上，可以在 Marketplace 安裝「Split!」，可以讓拆 PBI 的這件事情變得非常簡單。
在指定的 PBI 的編輯選單中選擇 Split，會彈出小視窗，預設會自動帶出此 PBI 下未完成的任務，當你點擊右下方的藍色 Split 按鈕後，會新增一張同樣內容的 PBI 在下一個 Sprint，並且將未完成的任務從舊 PBI 移動到新 PBI 中。
最後，在處理未完成的 PBI 時，持續的透明度、快速的反饋、以及從過程中學習的文化是非常重要的。這有助於團隊不斷改進，提高未來 Sprint 的成功機會。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
