有參與過敏捷開發的人一定聽過 story point，網路上也很多有關 story point 的解釋以及如了運用， 他主要是協助衡量團隊的開發狀況，讓 PM 可以再有一定的基準下去跟其他部門溝通，如產品行銷或是活動銷售等等。 但是不是真的有了 story point 就一定可以讓產品或專案順利進行？ 有沒有可能有了 story point 但還是遇到一堆狀況？
永遠估不準的 Story Point
有沒有遇過這個狀況，在 sprint lanning 時團隊評估這個 sprint 可以完成 40 點，但 sprint 結束時卻只完成了 25~30 點， 常見的原因可能有這幾種：
- ticket 的點數估不準（如後端工程師估一同評估前端工程師的 ticket ）
- 評估 ticket 時忘記某個項目也要做（如 App 新功能只評估畫面開發，遺漏 API 串接）
- 實作 ticket 時出現預期之外問題或任務（在串接第三方平台時，回的參數與文件給的不同）
這些狀況都可能對在進行中的 sprint 造成一些風險，當然一般來說還是有辦法解決， 通常會在 Retrospective meeting 中去討論如何避免這次該遇到的困難，如後端工程師需要了解前端的開發不只有畫面，也包含邏輯； 與第三方廠商串接資料時需要先確認文件與實際提供的參數是否相同等事項，並期待下次再評估點數時可以更貼近團隊的狀況。
但，有沒有就是沒辦法解決的狀況？如不管討論幾次總是會出現預期之外的問題，或是 ticket 總是會在 sprint 中不斷地長大， 導致需要在 sprint 去調整開發進度，接著去跟其他部門溝通 Delay 的狀況呢？
以 Sprint Goals 為導向，Story Point 僅是參考
在執行敏捷開發的過程中，團隊可能覺得目標是『完成全部的 story point』， 但如果遇到了進度不如預期，會很容易掉入一個互相踢皮球的狀況，如『 PM 安排太多事情了拉』， 『這個 sprint 少一天沒辦法做這麼多啊』、『為什麼工程師可以做這麼慢，這不是很簡單嗎？』、『做不完大家都有鍋啊』之類的情境內。
可以試著以 Sprint Goals 作為團隊的目標，如『我們與 ABC company 在 xx/yy 有聯合行銷活動，所以這個 sprint 需要完成 XYZ 功能的開發與測試，讓行銷及業務團隊可以如期的與 ABC company 舉辦活動來推廣及曝光產品。』，團隊成員就知道我們是為了什麼目標需要在這個 sprint 努力的把事情完成， 而不在只是像機器人一樣完成全部的 story point 而不知道為什麼要做完這些事情。
小團隊甚至可以不需要 Story Point
通常敏捷開發會需要 Refinement meeting 來進行 story point 的估算，這會議可能會需要耗時 1 ~ 1.5 hr 以上， 在團隊還小的時候，最重要的事情並非要走完所有的『形式會議』，而是把產品的開發出來並且保有一定的品質。 且團隊小，通常成員都需要負責多項任務，所以對於產品細節也都有一定的理解程度。 與其花大把時間去遵從這些形式，不如給團隊保有彈性，以 Sprint Goals 來對齊團隊目標，把更多的時間花在產品上而非形式或流程。
找出適合團隊的工作流程最重要
過去有很多種開發協作方式，敏捷相較於過去的瀑布流，優勢是可以讓產品更快速的投入市場迭代， 大量獲取用戶反饋來改進產品，我們應該是遵循這敏捷的精神而不是拘泥於形式。 若團隊適合的敏捷是以目標導向，不管怎樣就是在 sprint 內完成所設定的目標，那是否點數的估算就不那麼重要； 當然如果是有規模的團隊，需要非常有條理，需要以點數的完成率來評估績效，或許 story point 對於他們來說就有意義。
總結，找出適合團隊的工作流程，比拘泥於形式來得更重要！
