這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品
以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決，
並將其整理成為文章版更難完整記錄本場的內容
複雜度評估的兩個方式
在 Azure Boards 裡面可以安裝 Estimate 這個套件，在 Planning Meeting 的時候可以針對 User Story 進行估點計算，且這是一個線上即時的功能，即使遠端協作的團隊也可以達到很好的估點流程
這工具在出點的時候可以一起呈現，如果彼此點數落差大，可以進行多輪的討論，我們通常會用相對點數來讓團隊取得共識，此套件也能選擇很多範本
但如果你今天是有海量的需求，不想花太多時間一張一張評估，也許可以用 Affinity Estimation 這種方式，他的執行步驟是由PO解釋完單子後，將所有單子都建在看板上，透過團隊共同拖拉的方式，越左邊代表複雜度越小，越右邊越複雜，之後取中間當個分隔線，在給予不同大小的渠道。 最後一個步驟是針對鄰近的單子去比對，兩個大小是否是差不多大小，如果落差過大再微調
延伸閱讀: https://www.techagilist.com/agile/scrum/affinity-estimation-agile-estimation-method/
如何知道團隊成員工作量?
Planning 另外一個重點就是在 User Story 底下去拆技術細節去分工(Task)，雖然估時估不準，但我會建議還是能在 Original Estimate 這個欄位讓工程師評估一下這個單子預計要花的時間，通常一天我們會以 6hr 為單位，如果 Task 評估大於 12hr，代表顆粒度太大，需要再細拆，為什麼要這樣做呢? 因為搭配 Capacity 針對每個工程師每日可貢獻的時數，可以讓我們知道每個工程師拿的量會不會過多或過少
但記得一點，不要用這個來挑戰工程師產值，敏捷強調自我管理，信任制，為了共用目標努力，太在乎每日產出只會造成工程師給錯誤的資訊
在 Planning 檢視每個人的工作量是否平均
如果你想要看完整的演講影片，現在也已經傳到 Youtube
- 影片: https://www.youtube.com/watch?v=G0ggjY5kzF8
- 簡報: https://speakerdeck.com/kyleshen/dot-net-conf-taiwan-na-xie-nian-yong-azure-boards-jiao-fu-guo-de-chan-pin