理想情況下，一項功能應符合以下標準。
- 它應該提供 商業價值。
- 它應該是 可估量的 – 它必須具有足夠的定義，以便開發團隊能夠估算出實施它所需的工作量。
- 它應該是 足夠小 為了適應一次迭代——因此，如果它太大，就應該進一步分解。
- 它應該是 可測試 你應該了解一項功能需要通過哪些自動化或手動測試才能被客戶接受。
不同的方法論使用不同的術語來指稱功能。團隊可以自行決定使用哪種方法論或術語。極限編程 (XP) 使用「使用者故事」或「故事」來表示功能；Scrum 使用「產品待辦事項清單」來描述功能清單；功能驅動開發 (FED) 使用「功能」；而 DSDM 使用「需求」。同樣，統一過程 (UP) 也有各種輕量級版本，即敏捷統一過程 (Agile UP)，它們使用「需求」和/或「用例」來定義可增量交付的功能。最終目標都是一樣的——定期以小增量的方式交付業務價值，並且越快越好。
方法論差異
爭球 稱一個功能為 待辦事項這種做法往往比較細緻，還可以包括「設定生產硬體」或「研究 xyz 選項」等非功能性項目。
XP 稱一個功能為 故事這使得定義功能成為一種特別有用的方法。
數字數據管理系統 稱一個功能為 需求也可能包含系統功能以外的其他內容。
敏捷升級 從業者使用 要求 以及 用例 定義特徵.
特徵分解結構（FBS）
在詳細規劃階段， 敏捷開發 它傾向於採用功能性分解結構（FBS）方法，而不是瀑布式開發方法中常用的工作分解結構（WBS）。功能分解結構有以下幾個優點：
- 它們使得客戶和開發團隊之間能夠以雙方都能理解的方式溝通。
- 它們允許客戶根據業務價值來確定團隊工作的優先順序。
- 它們可以追蹤工作成果與實際產生的商業價值之間的關係。
可以先從大型功能入手，然後隨著時間的推移將其拆分成更小的功能。這樣可以讓客戶避免陷入過多的細節，直到真正需要這些細節來幫助實際設計和交付為止。
建立初始功能列表
發布計劃之前和 迭代計劃團隊需要盡快列出盡可能多的系統潛在功能。通常會指定專人負責收集功能（例如產品經理、客戶、專案經理、業務分析師或其他客戶代表），但功能需求可能來自多個方面。使用者、客戶、銷售、行銷、招標書、開發團隊成員、管理階層、競爭對手以及政府法規都可能成為功能來源。團隊的核心功能清單應設定一些控制措施，以防止重複條目、無法實現的功能以及過於模糊的需求。同時，應鼓勵團隊隨時添加新功能，以便將其納入優先排序和規劃流程。
初始功能清單可以是一個粗略的草圖，一個超集，用作規劃版本發布和首次迭代的輸入。它代表了系統目前的潛在發展方向，或許需要幾個版本才能實現。您無需等到所有功能都定義完畢才能開始。 交付軟體而且，你無需盲目地遵循最初的清單、描述或優先順序。敏捷開發的核心重點之一就是，這份清單（和其他所有東西一樣）會隨著迭代不斷演進。
假設在確定幾個關鍵功能之前，已經完成了一個粗略的功能列表，制定了發布計劃和迭代計劃，並完成了第一次迭代。這些關鍵功能會整合到不斷改進的發布計劃和後續迭代中，並儘快交付。但同時，時間並沒有被浪費。團隊會盡快開始交付價值，並建立必要的基礎設施，使專案能夠隨著時間的推移適應新的優先順序、資訊和業務動態。
功能清單
在製定功能清單時，功能最初會用一段簡短的文字描述，通常為 2-4 句話。這段描述是功能的概要概括，是初步理解的佔位符，也是後續溝通的基礎。它就像一篇即將撰寫的文章的標題。目標是用適量的篇幅描述功能，以便對功能的大小、複雜性和優先順序與其他功能進行比較，從而形成合理的理解。更多細節將在後續工作中逐步改善。 迭代計劃但是，在迭代過程中，隨著客戶和開發人員進行充分的討論以實現該功能，或者（在某些方法中）創建確定性地指定該功能的自動化驗收測試，可以逐漸形成對該功能的精確、具體的理解。
有用的參考資料
用戶故事
應用程式使用者故事：用於敏捷軟體開發 作者：麥克‧科恩
線上研討會
組織功能
管理冗長的功能清單可能很困難。透過指定類別、更高層級的功能分組、業務價值或優先順序以及風險來組織功能非常有幫助。依這些不同的屬性進行篩選和排序，可以將龐大的功能清單分解成易於管理的小塊。
所有功能清單應按順序排列，以便專案團隊能夠輕鬆了解哪些功能最有價值。如果專案開始時有 100 個功能，其中 50 個功能屬於「高」優先順序的情況並不少見。對這些功能進行順序排序有助於識別出「高中之高」的功能，從而優先完成這些功能，以最大限度地提高交付價值。
風險會計處理
對於某些功能相關的風險，可能需要額外考慮。有些功能涉及團隊不熟悉的全新設計、架構、框架或演算法，或本身就存在風險。即使這些功能並非最具商業價值，通常也應該提高它們的優先級，以便在早期迭代中優先處理。如果在專案早期就著手處理高風險功能，但由於某種原因最終無法實現，團隊仍然有時間做出反應並找到替代方案。這可以最大限度地降低專案的整體風險。開發團隊有責任與客戶緊密合作，共同辨識這類問題、風險和依賴關係。最終，功能優先順序由客戶決定，但此關鍵過程不應孤立進行。優秀的團隊會在整個專案生命週期中通力合作，既創造價值又降低風險。
特徵估計
在確定功能之後，客戶通常會與關鍵開發利害關係人合作，制定功能估算。功能估算旨在提供初步的、概括性的估算，用於指導後續工作。 發布計劃 以及迭代計劃。參與估算的利害關係人可能包括架構師、技術主管、開發人員、測試人員、文案和管理人員。許多組織都建立了對應的流程，讓各個團隊協作快速提供初步估算。這一步驟有助於初步確定是否需要將功能進一步分解。
在初步估算功能時，目標是快速達成一個合理的高層次估算。與其糾結於某個功能是否正好需要 17.5 個創意小時（或用小熊軟糖、堅果或其他任何單位來衡量；詳見下文），不如在極短的時間內盡可能接近這個估算值。例如，如果只需兩分鐘就能達成共識，認為某個功能需要兩到三天才能實現，而精確估算 17.5 個創意小時卻需要 30 分鐘，那麼前者更可取。當團隊成員意見不一致時，為了確定一個統一的估算值，團隊可以取平均值、制定一個合理的近似值、始終採用最佳情況，或者在情況較為複雜時，使用包含最佳情況、最差情況和預期估算值的計算方法。無論如何，關於不同估算值的討論通常都能帶來有用的信息。
定義和估算功能的過程起初可能比較困難，團隊在初次實施時可能需要多次會議才能熟悉並適應這種行之有效的方法。隨著時間的推移，將功能分解成可以在單次迭代中交付的工作單元會變得更加容易。團隊會越來越擅長實踐，而敏捷開發允許團隊在每次發布和迭代中進行估算練習。
估算單位
估算本質上是不準確的，開發人員歷來都難以準確估算完成一項開發任務所需的所有時間。實際程式設計時間的估算通常也不準確（尤其是在沒有與實際數據進行嚴格比較的情況下）。但非編程時間更難精確估算。如果有人問你開車穿過城市需要多長時間，你會怎麼回答？你會使用相對時間。 “非高峰時段，天氣好，沒有施工的話，大概一個小時；否則可能要兩個小時”，等等。這些外在因素無法控制，也難以預測。除了編寫程式碼，程式設計師還要花時間進行測試、撰寫文件、設計、參加會議和評審、處理電子郵件等等。與程式設計工作相比，非程式設計工作難以預測或控制。它會因行業、組織、季節以及組織面臨的各種外部壓力而改變。
有些團隊要求程式設計師將所有非程式設計活動都納入估算範圍。但正如我們所說，這並非易事。對於特定的敏捷項目，在團隊能夠準確衡量非程式設計活動所花費的時間之前，他們就能了解完成不同功能所需的相對工作量，並據此進行規劃。因此，敏捷團隊更傾向於將估算重點放在最容易估算和衡量的內容上：實際的程式設計工作。他們關注的是每個功能和技術任務所需的工作量，並與其他功能和技術任務進行比較。他們允許非程式活動所消耗的時間在幾次迭代後隨著實際速度的提升而逐漸明朗。敏捷團隊主要使用兩種估算單位來集中精力於程式設計工作：
- 工作單元
- 理想時間
工作單元
工作單位是一種相對計量單位，我們希望它絕對不會與實際時間混淆。例如：
- 點數
- 小熊軟糖
- 英尺磅
- 時間模糊單位 (NUTs)
這些數值代表了實現某個功能（或任務）所需的相對工作量，與其他功能（或任務）相比。只有當團隊穩定下來，達到一定的開發速度（通常需要幾次迭代）後，才能開始將這些工作單元對應到實際時間單位。這正是開發速度的意義所在：描述團隊在單位實際時間內能完成多少工作。
一旦團隊或組織就估算單位達成一致，就應該努力執行，並堅持其最初的定義。尤其是在專案初期，每個人都應該避免試圖將這些單位精確地對應到時間單位。
理想時間
與工作單元類似，理想時間也不包含非程式設計時間。當團隊使用理想時間進行估算時，他們明確指的是完成某個功能或任務所需的程式設計師時間，並與其他功能或任務進行比較。同樣，在最初幾次迭代中，估算歷史會不斷積累，實際開發速度會逐漸顯現，理想時間也可以映射到實際的、經過的時間。
許多採用理想工時的團隊發現，最終實際工作量往往比程式設計師最初的預估高出 1-2 倍，並且經過幾次迭代後，這一比例會穩定在一個可接受的範圍內。雖然每個任務的實際工時與理想工時的比例會有所不同，但在整個迭代周期內，團隊最終確定的比例通常相當穩定。對於特定團隊而言，了解理想工時與實際工時的歷史比例對於規劃發佈版本尤其重要。例如，團隊可以快速查看所需功能，並給出 200 個理想工時的粗略估計。如果團隊以往的理想工時與實際工時比例約為 2.5，那麼團隊就可以比較有信心提交 500 個專案工時的預估。在固定報價的情況下，這種預估是可靠的。
相對估計
許多敏捷團隊採用相對估算方法來估算功能。他們不是在一系列單位長度上估算功能，而是選擇幾個（三到五個）相對估算類別或區間，並根據這些類別來估算所有功能。
功能規劃與任務規劃
雖然規劃初期階段的重點在於速度和每個功能的相對工作量，但最終必須將功能分解為各個任務，並進行更精確的估算。這通常發生在發布計劃和迭代計劃階段。一般來說，功能估算和任務估算用於不同的目的：
- 功能估算有助於推動跨版本和迭代的進度安排。
- 任務估算有助於控制迭代過程中的資源分配。
由於特徵的估計值和任務估計值用途不同，因此它們不必完全一致。然而，在一定範圍的特徵中，特徵估計值和這些特徵的任務估計值總和之間至少應該存在大致的相關性。
常見問題
一個功能有多大？
這在很大程度上取決於團隊正在進行的開發工作。一般來說，一個功能應該要夠小，可以在一次迭代中完成，同時也要夠大，值得安排時間。例如，你肯定不希望一個十人團隊在一個月的迭代週期內只安排一個需要一小時才能完成的功能。這樣一來，需要安排和追蹤的任務就太多了。如果確實存在一些非常小的功能變更，通常最好將這些小變更合併成一個更大的任務，以便於安排時間。將每個需要一小時的工作量都作為該功能下的一個任務。
修復漏洞算是功能嗎？
確實可以。例如，Scrum 教導團隊所有需要完成的工作都應該列入待辦事項清單。處理缺陷的常用方法包括：1）為每個缺陷建立一個功能項；2）在每次迭代中建立一個名為「修復缺陷」的功能項，並詳細列出需要修復的缺陷清單或類型；3）單獨處理缺陷，不記錄修復時間。團隊預計遇到的缺陷數量和大小應該是決定選擇哪種方法的重要因素。
為什麼要估算特徵？
功能估算有助於指導發布計劃和迭代計劃中的優先順序和進度安排。要了解在給定時間段內需要安排多少工作，您必須估算每個工作項目的大小。另請參閱 敏捷速度如果兩個功能的商業價值相同，但一個功能的規模只有另一個功能的一半，那麼團隊優先開發第一個功能效率更高，因此它的優先順序應該高於第二個功能。
如果任務估算值加起來不符，我們是否應該更新功能估算值？
不，功能估算決定進度安排，任務估算決定資源分配。雖然兩者之間應該存在相關性，但並不需要完全一致。
