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

回想您上次自駕旅行的經驗。 是否花費了您預期的時間，或者是否遇到了意想不到的時間耗損，例如交通堵塞？ 規劃和估計專案可能會有這種感覺。 意外的障礙和專案的不確定性可能會延遲專案的時間軸，並導致範疇潛變。 而且，就像在您的行駛中一樣，您可能會發現自己處於從不預期的地方，例如超出預算和表現不佳。 

這就是估算技巧派上用場的時候。 藉助故事點等估算技巧，您可以準確地界定任務範圍，讓您和您的團隊更清楚地瞭解任務需要投入多少量，以及可能會在哪些地方出現問題。 讓我們深入瞭解故事點的優勢以及使用方法。 

什麽是故事點？

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

一般而言，故事點會考慮三個可能影響任務範圍和投入量的因素，故事點的數值也會隨之增加。 由於故事點是相對的，因此您可以透過考慮這些詳細資料並將類似任務進行比較來找到其數值。

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

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

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

需要瞭解的一個重要事項是，故事點是相對的，這意味著它們的相對價值和彼此之間的比率才是重要的，而不是它們的實際數值。

故事點與基於時間的估計

您可能會想，為什麼不直接使用時間來估計任務呢？ 您並沒有錯：以時間為基礎 (或以小時為基礎) 的估計是一種熱門的工作範疇界定方式。 

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

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

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

現在您已瞭解什麼是故事點，接著讓我們一起瞭解如何估計故事點，以便界定使用者故事的範圍。 

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

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

提示：請記住，故事點的比率很重要，而非實際數字。 換句話說，指派給故事點為 2 的任務，其投入量應該是指派給故事點為 1 的任務的兩倍。 指派給故事點為 3 的任務，其投入量應為指派給故事點為 2 的任務的一倍半。 您可以看到我們的目的。 

2. 確定您的故事點比例 

接下來，請確定您的故事點順序。 這將成為團隊在估計會議中指派故事點時使用的評分方法 (稍後將詳細介紹)。 序列很有幫助，因為它迫使您的團隊專注於數字之間的相對大小，從而使估計複雜的任務變得更容易。 那麼，您應該使用哪個故事點序列呢？ 費氏數列是一個數列，其中每個數字都是前兩個數字的總和，在敏捷式估計中很受歡迎。 但這可能會變得很複雜。 如果數值讓您的團隊感到不知所措，請嘗試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) 是有原因的，因為它們使估算投入量變得更加容易，並簡化了衝刺規劃。 但這還不是全部。 以下是使用敏捷故事點的其他幾個好處：

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

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

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

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

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

與產品負責人一起進行有效的故事點估算 

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

若要在故事點估算期間與產品負責人有效協作：

• 邀請產品負責人參加預估會議和規劃撲克會議。

• 鼓勵產品負責人闡明要求、功能並回答問題。

• 與產品負責人討論每個故事的商業價值和使用者影響。

• 確保產品負責人瞭解故事點和相對規模的概念。

• 與產品負責人合作，將大型故事分解為較小、可估算的部分。

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

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

故事點的世界並不容易。 故事點可簡化專案管理流程，但前提是您在估計時避免了某些錯誤。 以下是團隊在預估故事點時會犯的一些常見錯誤，以及如何避免這些錯誤。 

使用非相對的故事點 

故事點的相對性使您的團隊更容易瞭解任務之間的比較情況。 這就是為什麼您不應該隨意指派點數。 請記住：故事點應該相對於彼此進行擴展。 

將故事點等同於小時 

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

故事點估算不一致

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

過度強調精確度 

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

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

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

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

故事點是專案管理拼圖的重要組成部分。 但是，當您的待辦項目組織良好並與團隊的工作相符時，正確估計投入量並使任務達標就容易得多。 Asana 可隨時為您提供協助。 使用與團隊一樣協作的衝刺規劃範本，組織待辦項目、追蹤敏捷專案，並與團隊進行有效溝通。