這篇我想藉由女團 NMIXX 的新歌 DICE，分享我們團隊從「沒在估點數」，轉變成「很會估點數」的過程。

我們團隊由設計師和文案組成，任務包含：設計網站介面、製作廣告、規劃 UI Flow、整理 Design Guidleine 等等。工作項目多元，就像女團 NMIXX 團名的意義──混合、充滿未知數。

因為工作項目繁雜，也常面臨客戶的改動，一開始團隊很難為各項目估點數 (Story Point)，造成的影響是：團隊無法量化每週的產出，也無法觀察長期的產能。

為了跑敏捷開發，在 Scrum Master 林書緯的引導下，我們進行以下步驟，逐步建立「相對估算法」。

Story Point 相對估算法

1. 歸納過往的工作

團隊進行了一次工作坊，在一張又一張的卡片上，列出一個又一個之前做過的項目，並運用卡片分類法 (Card sorting) 將類似工作量的項目分成一組。這裡的工作量是指耗費的時間和複雜度。

2. 來玩比大小

接著，團隊將各組歸納好的項目，互相比大小，對應費式數列的數字大小：1 、2 、3 、5 、8，就能將工作耗費的時間和複雜度量化成數字。例如下圖，製造一台腳踏車的 Story Point 估算為 2，因為相對於製造機車和汽車，製造腳踏車所需的時間較短、複雜度較小。

圖片來源

3. 建立團隊估算的基準

透過工作坊，團隊建立了共識，整理了一張 【Story Size 對照表】，舉例如下：

• 整理設計元件，點數為 3
• 製作一張廣告，點數為 5
• 切版一個網站，點數為 8

接下來，在每次 PBR 產品待辦清單精煉會議中，團隊會參考【Story Size 對照表】來估點數，若遇到彼此想法不同時，也能討論為什麼覺得點數比較大、或比較小。

Story Point 量化了設計團隊的產能，也能幫助 Product Owner 估算專案何時能交付。

估算 Story Point 的過程，是團隊一起討論產生共識，而不是資深成員下定論，就像 NMIXX 在新歌 DICE 所唱，是一起打造的分數。

事情發展，和想像不一樣

但敏捷開發跑起來，還是會遇到天不時、地不利、人不和的 Drama 時刻。讓團隊成員不禁拍著額頭嘆道：「早知道我就估大一點...」。這種情況，我們會將點數估算的落差記錄在 Story 卡片上，並將這次的經驗學習，迭代到未來的點數估算過程中。

估完點數，Roll the Dice～展開冒險吧！