故事點：敏捷式使用者故事的估算指南

想想您上次進行公路旅行的情況。 花費的時間是否與您預期的一樣，或者您是否遇到了意想不到的時間浪費，例如交通堵塞？ 規劃和估算專案可能會有這樣的感覺。 意外障礙和專案不確定性可能會延遲您的專案時間軸，並導致範疇潛變。 而且，就像在開車時一樣，您可能會發現自己處於從未預期的境地，例如超出預算和表現不佳。 

這就是估算技巧派上用場的時候。 透過故事點等估算技術，您可以準確地確定任務範圍，讓您和您的團隊更清楚地瞭解任務所需的投入量以及可能出現問題的地方。 一起來深入瞭解故事點的優點以及使用方法。 

什麼是故事點？

故事點是一種估算完成產品待辦項目中使用者故事所需投入量的方法。 您通常會在衝刺規劃會議之前估算故事點，因為這是您的團隊確定他們在即將到來的衝刺中可以完成多少工作的時候。 

通常，故事點會考慮到三個可能影響任務範疇和投入量的因素，而故事點的數值會隨之增加。 由於故事點是相對的，您可以透過考慮這些詳細資料並將類似任務彼此比較來找到它們的價值。

• 風險是與任務相關的總風險或不確定性。 例如，如果任務涉及第三方、承包商或專案關係人，則可能會增加風險。

• 重複是團隊在類似任務上的經驗。 

• 複雜度是任務的難度 (以及任務目標的清晰度)。 

有一點很重要，就是故事點是相對的，這意味著它們的相對價值和彼此的比率才是重要的，而非它們的實際數值。

故事點與基於時間的估算

您可能會想，為什麼不直接使用時間來估算任務？ 您沒有錯：以時間為基礎 (或以小時為基礎) 的估算是一種流行的工作範圍確定方法。 

但這樣做有個缺點，與故事點不同的是，以時間為基礎的估算並未考慮到複雜性、風險或不確定性。 它們還取決於每個團隊成員的個人估計，這可能會因資歷、對任務的理解以及類似任務的經驗而異。 

敏捷故事點透過鼓勵協作並考慮風險、複雜性和經驗來解決這些潛在問題。 結果就是一個通用的評分系統，讓團隊成員保持一致。

實施和估算故事點的六個步驟

現在您已經瞭解什麼是故事點，讓我們來看看如何估算故事點以確定使用者故事的範疇。 

1. 向您的團隊介紹故事點

對故事點有深入的理解對於成功至關重要。 為了讓您的團隊輕鬆進入流程，請向他們介紹故事點的基礎知識和優點。 特別是，請確保他們瞭解故事點數字需要相對於彼此進行縮放。

提示：請記住，故事點的比例很重要，而非實際數字。 換句話說，分配了 2 個故事點的任務應該比分配了 1 個故事點的任務多兩倍的投入量。 分配了三個故事點的任務應該需要分配了兩個故事點的任務的一半投入量。 您可以看到我們的思路。 

2. 確定您的故事點比例 

接下來，請確定您的故事點序列。 這將成為您的團隊在估算會議中用於分配故事點的評分方法 (稍後會詳細介紹)。 序列很有幫助，因為它迫使您的團隊專注於數字之間的相對大小，從而更容易估算複雜的任務。 那麼，您應該使用哪種故事點序列呢？ 費氏數列 (Fibonacci sequence) 是一個數列，其中每個數字都是前兩個數字的總和，這在敏捷法的估算中很受歡迎。 但這可能會變得很複雜。 如果數值讓您的團隊感到不知所措，不妨嘗試 T 恤尺寸法。 顧名思義，這個序列會將任務分解為更易於管理的尺寸，以 T 恤尺寸為基礎：XS、S、M、L、XL 和 XXL。 

提示：在敏捷法中進行估算時，團隊通常會將費氏數列更改為 0、0.5、1、2、3、5、8、13、20、40 和 100，以便於使用。 

3. 建立故事點矩陣

故事點矩陣基本上是故事點序列的充實版本。 它可作為您的估算會議的基準，並讓您的團隊更清楚地瞭解如何為每個任務評分。 如果您之前沒有使用過故事點，我們建議您利用您對團隊通常完成的任務以及與之相關的複雜性、不確定性和投入量的知識。

如您所見，隨著任務的投入量、複雜程度和風險增加，故事點數值也會增加。 

提示：隨著您進行衝刺並更好地瞭解與團隊任務相關的投入量，您的故事點矩陣將會發展。 不要擔心第一次就能做到完美，而是要從團隊的典型任務開始，並計劃在每次衝刺後重新評估矩陣。

4. 舉行規劃撲克會議

現在您已經選擇了故事點序列並建立了故事點矩陣，是時候深入瞭解問題的核心了：透過規劃撲克會議來估算您的故事點。 

規劃撲克的目標是為使用者故事指定故事點，讓您的團隊維持資訊同步，並瞭解團隊在即將到來的衝刺中可以完成多少任務。 規劃撲克會讓每個人都能對即將到來的工作進行評估。 由於整個團隊都參與其中，您可以確保自己是根據不同的意見分配故事點，並防止無意識的偏見。 

以下說明如何成功舉辦規劃撲克會議。    

• 為您的團隊提供一個明確的故事點矩陣以供參考，以及一組描述故事點序列的卡片。 您可以自行建立卡片或下載一組卡片。   

• 選擇一個使用者故事。 

• 與您的團隊討論故事，包括涉及的內容以及成功的樣貌。 

• 讓每位團隊成員私下選擇他們認為代表完成故事所需投入量的故事點卡。 

• 讓您的團隊同時展示他們的卡片選擇。 如果故事點一致，請繼續下一個使用者故事。 如果故事點不一致，請繼續討論使用者故事，直到達成共識為止。

• 重複此流程，直到您為產品待辦項目中的所有任務指定故事點為止。 

• 使用故事點矩陣作為基準，確定團隊在即將到來的衝刺中可以完成多少任務。

提示：在團隊確定待辦項目的優先順序後，並在衝刺開始之前，規劃召開規劃撲克會議。 規劃撲克會議可能需要兩到四個小時 (而您的第一次會議可能需要更長時間)，因此請據此進行規劃。 

5. 規劃並執行您的衝刺 

如果這是您第一次使用故事點，在完成第一次完整的衝刺之前，您不會確切知道每次衝刺可以完成多少故事點 (也稱為「衝刺速度」)。 這沒關係。 在衝刺規劃會議中，根據任務的複雜性和故事點的價值，盡可能估算衝刺中應包含的故事點數。 

提示：您的第一次衝刺可能包含大量低價值的故事點、少量高價值的故事點或兩者的混合。 隨著時間推移，您將瞭解哪些方法最適合您的團隊，並根據團隊的回饋改進流程。 

6. 持續改善您的故事點估算

使用故事點已完成第一次衝刺後，就可以專注於敏捷架構的主題：持續改進。 為此，請與團隊一起討論哪些方面進展順利，哪些方面仍可改進。 您可以單獨召開會議，或將其納入衝刺回顧中。 

詢問團隊一些問題，例如故事點的範圍是否正確、他們遇到了哪些意想不到的專案瓶頸，以及未能達成目標的其他原因。 利用這些答案來改進下一次衝刺的流程。 如有需要，請重新評估您的故事點序列或故事點矩陣。 

提示：確定團隊的速度後，請使用該數字分配故事點，並查看團隊完成整個專案所需的衝刺次數。

如何在敏捷專案中使用故事點

眾所周知，提前規劃是專案管理的關鍵。 無法妥善規劃工作範疇和排定工作排程，可能會導致錯過期限、範疇潛變和專案失敗。 但如果這聽起來很可怕，請不要擔心。 故事點可以提供協助。 

為了更好地瞭解故事點，我們來看看如何在敏捷架構中使用它們：

• 首先，為每個所需功能撰寫使用者故事。 使用者故事遵循「身為〔角色〕，我想要〔目標〕，以便獲得〔結果或效益〕」的格式。

• 將您的使用者故事新增至產品待辦項目。 

• 為每個使用者故事指派故事點，以估算投入量。 

• 使用故事點從待辦項目中選擇使用者故事，確保您為每次衝刺選擇了正確的工作「量」。 

• 執行您的衝刺。 

範例：假設您的使用者故事是「身為使用者，我想要能夠透過網站提交回饋和問題，以便更好地瞭解產品功能。」 您會為此使用者故事指定一個故事點，也就是您認為完成故事所需的投入量。 然後，您可以將故事分解為更小的任務，例如確定範圍和設計回饋表單、編寫表單的程式碼、暫存頁面和測試表單，以及發佈頁面。 

使用故事點的優點

故事點是估算技術的 MVP，這是有原因的，因為它們使估算投入量更容易，並簡化了衝刺規劃。 但這還不夠。 以下是使用敏捷故事點的其他幾個好處：

• 推動更快的規劃。 故事點是相對估算的衡量單位，這意味著您可以透過將一個故事點與類似的、已經估算過的工作項目進行比較來計算其價值。 使用相對評分方法可隨著時間的推移更快地進行估算，這對您的團隊來說是一大優勢。 

• 將不可預測性和風險納入考量。 敏捷故事點會考量未知和風險等因素。 在規劃中使用這些因素可以消除估算中的猜測，讓您更準確地確定投入量。

• 從您的規劃中消除技能偏見，並讓您的團隊維持資訊同步。 依賴個別團隊成員的估算並不總是最好的。 畢竟，資深團隊成員的投入量估計可能與初級團隊成員大不相同。 故事點透過規劃撲克會議的表單鼓勵協作，從而防止這些問題。 

• 建立有意義的期限。 沒有人喜歡隨意設定的期限，但當您使用其他基於時間量的估算技術時，通常會得到這樣的結果。 由於故事點更具細微差異，因此可以產生有意義的截止日期。  

• 建立更好的未來預估。 故事點的主要優點之一是它們具有適應性和可重複使用性。 這意味著，一旦您建立了故事點矩陣並進行了第一次衝刺，您就可以利用所學重新估算原始故事點值，並制定更準確的估算。 

與產品經理一起進行有效的故事點估算 

與產品經理密切合作對於準確的故事點估算至關重要。 產品經理可針對 Business 版、使用者優先順序和每項工作的驗收標準提供有價值的深入解析。 透過讓產品經理參與預估流程，敏捷團隊可以確保對需求的共同理解，並做出更明智的預估。

若要在故事點估算期間與產品經理有效協作：

• 邀請產品經理參加預估會議和規劃撲克會議。

• 鼓勵產品所有者釐清需求、功能並回答問題。

• 與產品所有者討論每個故事的 Business 版價值和使用者影響。

• 確保產品所有者瞭解故事點和相對規模的概念。

• 與產品所有者協作，將大型故事分解為較小、可估算的區塊。

範例：假設由開發團隊、Scrum 主持人和產品經理組成的 Scrum 團隊正在估算行動應用程式中新功能的使用者故事。 產品經理加入估算會議，並提供有關該功能對使用者的重要性和預期功能的其他背景資訊。 開發團隊查詢 Scrum 指南，以釐清驗收標準和邊緣案例。 產品經理和團隊一起討論故事的複雜性，並將其分解為更小、更易於管理的使用者故事。 透過與產品經理密切合作，團隊可以更好地瞭解需求，並提供更準確的故事點估算。

避免故事點估算中的常見陷阱

在故事點領域，並非一切都很容易。 故事點可簡化專案管理流程，但前提是您在估算時要避免某些錯誤。 以下是團隊在估算故事點時會犯的一些常見錯誤，以及如何避免這些錯誤。 

使用非相對的故事點 

故事點的相對性使您的團隊更容易瞭解任務之間的比較。 這就是您不應該隨意分配點數的原因。 請記住：故事點應該相對於彼此進行縮放。 

將故事點數與小時數相等 

由於時間估算並未考慮複雜性和不確定性等因素，因此使用小時估算或天數作為故事點與其目標背道而馳。 相反地，請考慮我們已經討論過的三個組成部分：複雜性、風險和重複性，以確定您的故事點數值。 

故事點估算不一致

故事點估算中的不一致性可能會導致混亂和規劃不準確。 確保您的團隊對每個故事點數值所代表的內容有共同的理解。 定期進行待辦項目完善會議和估算工作坊有助於維持一致性。

過度強調精確度 

雖然故事點估算旨在提高準確性，但追求完美的精確性會適得其反。 接受軟體開發中固有的不確定性，並使用故事點作為相對調整的工具，而不是以精確估算為目標。

未能從過去的故事點估算中學習 

透過反思過去的衝刺，持續改善您的故事點估算。 將完成故事所需的實際投入量與初始估計進行比較。 使用此回饋校準團隊對故事點的理解，並完善您的估算流程。 讓整個 Scrum 團隊 (包括測試人員) 參與其中，收集深入解析和指標，以改善您的敏捷實踐。

使用範本管理衝刺規劃和故事點

故事點是專案管理拼圖中的重要一塊。 但是，當您的待辦項目井然有序並與團隊的工作相符時，正確估算投入量並將任務推進至終點就容易得多。 Asana 可在此提供協助。 使用與團隊一樣協作的衝刺規劃範本，組織您的待辦項目、追蹤敏捷專案，並與團隊進行有效溝通。