我目前的團隊從正式開始使用 Story Point 到現在，有超過一年的時間了。平常工作時偶然的發現團隊內有一些不一樣的地方，於是想要寫篇文章來記錄一下。
其實大概半年前就想要寫的，拖著拖著居然又過了半年，拖延症真是個可怕的傢伙。
什麼是估點(Story Point)
簡單的說明一下，估點、估計點數、Story Point，它讓團隊用來幫 User Story 評估複雜度的工具。可以避免評估討論跟工時關連在一起，讓團隊更專注在溝通跟交流想法。
團隊簡介
我所在的開發團隊使用 Scrum 框架進行軟體開發，負責多個產品線，成員由幾位前端工程師跟後端工程師組成。每個人的開發經驗不一樣，多數是一兩年經驗。我是其中的後端工程師，所以這篇文章會是從團隊內部觀察的記錄。
熱身時期
由 Scrum Master 舉行了幾次的「估點工作坊」開始，帶大家認識 Story Point 這個工具。
接著在 Planning Meeting 嘗試估計 Story Point，這個時期是練習、推廣階段。當有遇到疑問而團隊不知道要怎麼辦的時候，會找 Scrum Master 討論要怎麼做比較好。又或是遇到太難以估點的時候，團隊會選擇暫時不估點。
這個時期的估點過程
- 使用 Planning Poker (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 無限大)
- 大家在討論要做什麼事才能夠完成 User Story 時，會拆分到很細小的工作，小到一個 function 或是 class
- Planning Meeting 的時間容易超過兩小時
各種的問題
導入估點時會遇到的問題，我們當然是一定有發生，常見的問題一個都沒有少：
- 覺得估點對完成工作沒有幫助，花很多時間討論，事情還是做不完
- 認為估點是一種承諾的工作時數，總是擔心會有預期外的事情發生，或是點數估太小會對自己的評價有不好的影響，所以只要會花時間的事情都要加到點數上 ex. 寫測試要加點數、Debug 要加時間
- 會考慮是誰做的，把自己對 task 的熟悉度加入估點的考量，每個人對點數往往有不一樣的見解
- 點數沒有參考基準，每個人對數字的定義都不一樣，會糾結在點數定議上
- 覺得拿牌很麻煩，不能直接用手比嗎?
實戰初期
經歷過數次的熱身後，在一次的 Retrospective Meeting，團隊重新再看一次 Story Point 的原則，並依據熱身時期的經驗討論出一份團隊的「估點原則」跟「溫馨小提醒」，希望團隊成員可以舒適的進行估點又不會走歪。
估點原則
- 會議要有主持人，控制會議流程與時間
- Timebox 2 小時，時間到需要有結論
- 確保大家對工作認知一致（包含 User Story、Task、DoD、AC、部署環境與內容）
- Product Owner 要一同參與 Planning
- 接手同產品線的人要一起估點
- 如果覺得自己有困難無法估點，提出說明取得團隊的認可後，可以不參與這次估點 (ex. 剛加入的新人或是有特別的專業知識不熟悉等等)
溫馨小提醒
- 先定義出最小的 User Story 基準 (ex. S)，再拿捏其他 User Story 大小
- 可以使用輔助工具協助估點進行（ex. 打開 UI/UX 的設計圖)
- 估點時，溫柔友善地與夥伴對談，得到確認後，可及時變更點數
- 快超時前先要有結論，其他細項另找人討論
這個時期的估點過程
- 估點過程是在估 Task Point，而非直接對 Story 估點
- 改用 T-Shirt Sizing (XS, S, M, L, XL)，避免團隊在估點時過度在意數字大概要多少比較精確
- 在 Planning Meeting 固定進行「估點」的環節，一個 User Story 討論完畢後，就進行估點
- 將 User Story 拆分出要執行的 Task，對每個 Task 進行估點，最後將所有的點數加總，就是 User Story 的點數了
- 把 T-Shirt Size 換算成 Story Point，開始統計每個 Sprint 團隊完成的點數
- Planning Meeting 的時間勉強能夠控制在兩小時左右，超時的次數不少
改變
「估點原則」出現後，時間控制有明顯的漸入佳境。當然我也不排除大家不想要每次都開會得很累，所以會主動的有一些改變。團隊在討論時會開始注意到離題的討論，適時的拉回主題。有主持人也確實讓會議的進行比較順暢，不管是在注意時間上，或是帶領團隊往下一個主題進行討論，都有相當的效果。
團隊在面對「多個產品線」的難題下「估點原則」也有幫助找到正確的人參與會議，以及讓討論聚焦在同一件事情上。
當出現點數不一樣，但是對 User Story 的說明都一致的時候，就會詢問大家是否「取大的點數」當做 User Story 的點數。
熟悉與轉變
就在有一次的 Planning Meeting 結束後，覺得怎麼這次開會特別的順暢，讓我開始有想法記錄自己觀察到的情況。
這個時期的估點過程
- 估點過程一樣是在估 Task Point，而非直接對 Story 估點
- 將 User Story 拆分出要執行的 task，可能會是用的 API、UI、Scheduler 等等的功能
- 對每個 task 進行估點
- 將所有 task 的點數加總，就是 User Story 的點數了
改變
Story Point 的資料逐漸累積下來之後，這些點數可以做比較的對象是過去的自己，再也沒有人會把 Story Point 認定為承諾工作時數了。
當大家對估點的經驗慢慢增加後
- 漸漸的不太會有人擔心估不準怎麼辦
- 當出現一次就所有人估計一樣的點數時，也反應出團隊的默契
- 當估點有落差時，團隊會討論是哪些事情造成差距，也會進一步去評估是否跟 User Story 有關係
估點的目標變成完整的功能，不再是程式碼程度的 function, class 等，所以漸漸的不會討論到寫程式的細節，相關的事就交給領取 User Story 的人自行去決定。討論過程不再聊太多細節也帶來一些額外的好處:
- 討論時間縮短
- 交流跟思考的資訊都會跟 User Story 有直接相關，不會有過多的資訊讓腦袋爆炸
當 Sprint 目標沒有達成時，團隊會討論影響達成目標的原因有哪些。
Product Owner 提出在 Refinement 加入估點環節，想要在 Planning 之前就有個粗略的點數，跟歷史點數比較評估下個 Sprint 有機會完成 Backlog 上多少個 User Story
受疫情影響，公司也視情況進行 Work From Home 或是分流上班，所有的會議都變成線上進行，估點的部份當然也不例外，我們就使用這個網站(https://www.scrumpoker-online.org/) 進行估點
近期的不一樣
這個時期的估點過程
- 從 T-Shirt Sizing 換成 Planning Poker，
- 對估點活動熟悉，想要有更多一些的點數選項，在遇到點數小的 Story 時，可以有更多的選擇 (ex. 超級簡單的工作就可以估計點數為 0)
- 開始試著直接估計 Story Point
- 討論 User Story 所描述的情境(Scenario)，整理出需要去完成的 Task
- 如果 User Story 有多個情境，會把不同的情境再分成多個 User Story
- 根據前面的討論，對 User Story 進行估點
改變
當發現估計點數跟實際執行的情況有落差時，團隊會討論造成這些差距的原因。可能是對 User Story 怎麼完成沒有把握，過度的加大點數。可能是把 User Story 想得太過簡單，還有很多沒有考慮到的部份。
當估點的單位變成是一個 Story 時，每個人在思考的焦點會是一個可以完整交付的 Story 不太會過度的在意跟討論細節，每個人對 User Story 的認識感覺比過往更加的完整。
繼續走下去
寫一寫感覺目前團隊的運作狀況好像還不錯，不過各種挑戰持續的出現，團隊還是有很多進步空間的。
列一下最近已知的問題:
- 新成員要怎麼跟上團隊的腳步? 新加入的成員，特別是對估點沒有概念的，感覺要把過去團隊走過的經歷再走過一遍。
- 討論的過程偶爾會卡卡的。會出現這個情況的因素很多，目前也只能見機行事。