搶story point評績效? 你認真?

面試提問小插曲

受到疫情影響，躲在家多寫幾篇文章，一方面幫自己整理腦中的思緒，另一方面多涉獵各類敏捷方法論(Agile Methodologies)，恰巧正逢接下來的畢業潮，想必今年因為疫情的緣故遠端面試會大興其道，想到這裡腦海突然浮現4年前在南港某大企業的面試經驗，當時和面試主管討論了他們在實施Scrum的情況，主管的一段話讓我心中冒出很大一個驚嘆號(!)

主管: 我們Sprint Planning估計完點數後，就讓大家來認領工作，通常點數的領取也會當作年終績效的評核依據。

當時對Scrum的理解還不夠深，其實沒有很清楚將Story Point作為獎金分配的做法是否真的有對團隊起到激勵作用，因此想藉著這個例子，和大家聊聊到底Story Point是個怎樣的存在?以它作為績效標準會帶來哪些影響呢?

故事點數 (Story Point) 定義

從Sprint Planning出發，當產品負責人將待辦項目清單依據商業價值排序過後，需要與開發團隊討論每一個項目所呈現的情境、成本、是否需要再切割等等議題，為了有效地評估該團隊在每個Sprint中消化項目的速度以及整體工作的概況，引入Story Point的概念來量化一個待辦項目的大小，這個大小本身沒有絕對的意義，主要是為了呈現該項目在所有人眼中可能具備的內容多寡。因此這其實是一種相對的數值，它可以是1~100，也可以是10~100不等，大小的範圍只要團隊在專案初期有一個具體共識即可，藉此讓大家對於所挑選項目彼此間的相對大小有比較的對象。

無感的誤區

理論上，每一個待辦項目都是由整個團隊所負責，並且其背後皆表示著一項可以被實現的用戶情境，因此不會由單一人員主導整個項目的開發。

這是敏捷導入初期所有成員可能會闖進的誤區，甚至連教練本身都沒來的及注意到這一點，即便我們懂得如何寫好一個使用者故事(User Story)，但在面對項目挑選的那一剎那，思維依然還停留在以前單兵作戰的年代。

因此剛開始時大家仍會慣性地挑選自己最習慣上手的項目，又重新落入功能性的思考方式(即Component Team的濫觴)。過去在Backlog的切割原則中，我曾經說過，待辦項目的切割必須是縱向的，意即它的表示方式必須能足夠表現情境的各個面向，而非僅是以功能性的角度看待，因此當情境的整合出現了狀況，通常反映出的是團隊整體的問題，而並非是單一個人的議題。

績效考核的後續

回到原來探討的主題 - 將Story Point作為個人績效考核的依據到底可不可行?