Scrum 系列：如何規劃團隊成員的合理工作量
將故事點填入 Task 的 remaining work 欄位，反映出每個人實際的工作量。
在 Sprint Planning 時，根據團隊速率 (Team Velocity)，整個團隊會規劃當前迭代 (Current Sprint) 的合理工作量。然而，我們如何確定每個人的工作量是否合理呢？
Azure DevOps 提供了一個稱為 Work Detail 的功能，能夠有效解決這個問題。
在 Sprint Planning 階段，開發人員會共同討論實作細節，並在每個 User Story 下建立相應的多個 Task。根據分工合作的情況，每個人會負責認領其中的 Task。
此外，開發人員還需在 Task 的「original estimate」欄位填入「預計完成的工時」。隨著任務的進展，他們會在「remaining work」欄位更新「剩餘的工作時數」。
詳細的 Work Detail 介紹可以參考 Azure DevOps 的官方文件。https://learn.microsoft.com/en-us/azure/devops/boards/sprints/adjust-work?view=azure-devops
然而，這種計算工作時數的方法並不普遍受到歡迎，在我過去輔導的團隊中，只有少數團隊持續使用，並認為其帶來實質幫助。對於大多數團隊而言，這種方式並不切實際，我觀察到主要有三個缺點：
- 精準的完成時數可能使產品負責人 (PO) 和開發主管產生錯誤的認知，認為每個人必須在預定的時程內完成。
- Task 必須在 Sprint Planning 時全部列舉出來。如果沒有，則無法保證這樣的規劃方式能確保每個人都承擔合理的工作量。
- 我們在 Story 的估算中使用故事點作為單位，但在 Task 的估算中則採用時數，這對團隊而言帶來額外的認知與學習成本。
因此，一些專家提出其實無需在 Task 上做時數的估算，相反，我們應確保 Task 的顆粒度足夠小，例如，一個 Task 應該能在一天內完成。若能採用此類細分方式，則在 Task 上進行估算似乎就不再那麼重要。
但是，上面的說法依舊無法完美的解決團隊遇到的兩個問題。第一個是開發主管希望了解每位團隊成員在當前迭代中的工作量是否合理；第二個是團隊成員不希望花費太多時間在估算上，尤其是填寫一些對於產品交付沒有太大幫助的資訊。
經過觀察多個團隊的運作方式後，我提出了以下這個機制，可以同時解決這兩個問題。
團隊仍然 Product Backlog Refinement 會議中，對於經過充分討論的 User Story，使用故事點做整體的估算。這個估算被視為初始的估算，提供給產品負責人關於待辦清單優先順序的參考。
然後，在Sprint Planning 會議中，團隊會根據團隊速率挑選合適的工作量，每位團隊成員根據認領到的 User Story 進行拆分，建立對應的 Task。此時，有兩種方式可以填入 Task 層級的估算。
第一種方法如上圖的上半部分所示，一個 User Story 由兩位團隊成員共同完成，Meredith有兩個 Task，Derek 有三個 Task。Meredith 根據她的兩個 Task，給出一個故事點作為整體的任務工作量；Derek 根據他的三個 Task，另外給出一個故事點作為整體的任務工作量。
第二種方法如上圖的下半部分所示，一個 User Story 被拆解為四個 Task，每位認領 Task 的團隊成員獨立給出估算。
上面兩種方式，我比較推薦第一種，比較簡單一些。當我們在 Task 層級估算完的總點數，如果有需要，也可以更新回 Story 層級的點數，當作第二次的估算值。
在 Azure DevOps 的設計中，我們可以通過設定 Column Option 來讓 remaining work欄 位在 Backlog 頁面顯示。在 User Story 的 remaining work 數值不需要手動填寫，系統會自動加總其下 Task 的 remaining work。
也許，對於一些熟悉 Azure DevOps 的人會認為，為什麼不利用 Task 的 effort欄位，在User Story 層級上通過 Sum of Effort 來加總 Task 的 effort 呢？主要是因為 Sum of Effort 欄位需要即時運算，其顯示速度較慢。
此外，這個方法也可以處理一個團隊經常面臨的問題，即當迭代結束時，未完成的 User Story 該如何處理。如果團隊傾向於將整個 User Story 移至下一個迭代以保持其完整性，例如，如果一個 User Story 的點數為 8，已完成 3 點，直接移到下一個迭代時，我們無法很容易地知道尚有多少點數的工作未完成。
在這種情況下，團隊成員可以調整 Task 中的 remaining work 來反映實際剩餘的工作量。
總結一下，如果想要利用故事點規劃團隊成員的合理工作量，可以以 Story 為單位，請一起合作的 Developer，各自挑選一張自己的 Task，在 remaining work 欄位中填入自己負責部分的整體任務工作量。
