軟件項目工作量估算從估算根據上看可以分成以下兩類：
1，基于范圍估算
2，基于工作量估算
基于范圍估算的情況下，需要估算軟件項目的范圍。本文首先來看范圍方面的問題。
問題1：如何表達范圍？
軟件產品或項目的功能范圍是觸及軟件開發和交易的本錢、項目資源投入的預測、項目保護本錢的預算、項目質量管理的要求和產品上市的時間等方面的關鍵指標。因此，進行軟件產品的功能范圍丈量顯得特別重要。
如何丈量軟件范圍這個問題自軟件工程誕生起就1直是這個領域的焦點問題。剛開始，人們很自然的使用代碼行數作為范圍的表達。但是作為范圍表達方式的代碼行數隨著時間和技術的發展，愈來愈不正確了，主要緣由是1，新工具自動生成大量代碼行；2復用構件或源代碼；3，難以辨別新開發代碼和舊代碼。而且最重要的是源代碼行數的實際丈量只能在軟件項目開發的后期，缺少在前期較精確指點項目的能力。
世界上各個組織都看到了代碼行作為范圍表達方式的弊端，紛紜發展了各自的范圍表達方式，其中IFPUG的功能點計數是其中有顯著影響的。但是由于范圍度量存在各種各樣的情況，IFPUG的方法并沒有統治地位，出現了多種范圍度量方法。目前，國內外軟件領域的專家對軟件功能范圍丈量展開了極富成效的研究，提出了各類工業標準。國際標準化組織（ISO）和國際電工委員會（IEC）聯合技術委員會分別于1998、2002和2003年推出了軟件功能范圍丈量方面的系列標準。國際標準化組織ISO/IEC相繼發表了4個功能范圍丈量方法的標準，它們是：
――ISO/IEC 19761（COSMIC-FFP方法）；
――ISO/IEC 20926（IFPUG方法）；
――ISO/IEC 20968（MkⅡ方法）；
――ISO/IEC 24750（NESMA方法）。
其中，COSMIC-FFP方法聲明可以利用于管理信息系統（MIS）和實時類型2類軟件，IFPUG方法聲明可用于所有類型的軟件，MkⅡ方法聲明可用于邏輯事務能被肯定的任何軟件類型，NESMA方法非常類似于IFPUG方法也能夠用于所有軟件類型。
我國也10分重視這類標準的研究，于2001年開始了這方面的工作。
我國相繼發布了GB/T 18491.1～6《信息技術 軟件丈量 功能范圍丈量》的系列標準，但具體的丈量方法不包括在該系列標準中。由中國工業和信息化部支持的《軟件工程 軟件功能范圍丈量方法 功能點計數》（征求意見稿）于2011年9月1日完成，現在正處于意見征集階段，這個標準非等效采取了ISO/IEC 20926:2003，為所有類型的軟件開發的全生存周期提供了1種統1的軟件功能范圍計數方法。
除以上方法，常見的方法還有：
其它各類功能點方法
代碼行數 LOC
數據點
對象點
用例點
故事點，故事點是比較特殊的1個方法，下文還有說明。
很多公司發展了自己的功能范圍丈量方法。
問題2：如何丈量范圍？
以上這些范圍丈量方法的基本框架是相同的，下面是1個概要的介紹。
首先對做所丈量對象進行分解，針對分解得到的各個部份，估算或丈量模塊的初始范圍u（有些場合稱為未調劑功能點），乘以模塊級調理參數f1，得到模塊1次調劑后的范圍，將所有1次調劑后的范圍累加得到1次調劑后的總范圍，乘以整體調理系數f2，得到2次調劑后的總范圍s，見以下公式：
總范圍S = (西格瑪u*f1)*f2
有些方法只有1次調劑，有些方法有上述的2次調劑。
問題3：如何根據范圍估算工作量
經過前人的大量研究，認為范圍與工作量的數學關系如以下公式所示：
估算工作量e = a * S的b次方 + c
s是代表了范圍, a,b,c是參數，其值的取得需要大量數據分析，1般采取非線性轉換到線性，再進行線性回歸分析。b的取值1般是1到1.2之間。
從以上公式可以看出，隨著范圍s的增加，工作量e是指數級增長，表明了軟件項目范圍越大，所需要的工作量增加得更多，表明了軟件開發范圍不經濟的情況，這和我們直觀的感受是1致的。
世界上各個軟件生產率研究組織（比如ISBSG，SPR，日本的IPA SEC等）搜集了不計其數個項目數據，展開各種各樣的數學分析，試圖得到在各種情況下 a, b ,c 的取值。
在第5屆世界軟件質量大會上，來自Toyo University的野中誠（Makoto Nonaka）介紹了日本IPA SEC組織（http://sec.ipa.go.jp/），舉了某種情況下的1個工作量估算公式：
工數 = e的0.542次方*FP的1.154次方 = 1.719*FP的1.154次方。
對1般的場合，其范圍在1定有限的范圍以內，那末可以假定工作量與范圍的關系是簡單的線性正相干，那末上述公式就變成：
估算工作量e = a * S，即b=1, c=0 。 那末參數 a 就是 表明了生產率，a的單位是 工作量/單位范圍，比如8工時/FP；另外1種生產率單位是范圍/單位工作量，比如30FP/Man-month，如果采取常見的生產率單位，那末a就是生產率的倒數。
這類做法是更容易為各方所理解，在很多組織里常見到這個做法。
對照基于范圍的工作量估算，直接的工作量估算方法所積累的數據和資料就少了,沒有看到哪一個組織在搜集積累這類數據，這與直接工作量估算方法本身的特點也有關系。
下面來看看直接工作量估算方面的問題。
問題4，如何表達工作量？
工作量的單位1般是工時、人天、人月、人年。這些不同的單位是可以換算的。不同單位換算其實不麻煩，在同1個國家沒有差異，在不同國家由于法定假期的不同，1人月所對應的人天多是不同的，但差異其實不大。真正麻煩的是工作量表達有以下兩種：
1，工作量
2，理想工作量
而工作量也有差異，有些地方是計毛時，比如1天都在某項目上工作，就直接記為8工時，有些地方是計凈時，雖然1天都在某項目上工作，但會把諸如非直接相干的工作（如部門例會、參加其它項目評審）等等剝離，1天在某項目上的工作量只有5工時。 這樣看，可以發現計凈時的工作量與理想工作量比較接近，但注意其實不完全相等。
問題5，如何直接估算工作量？
主要的思路是分解和類比。
把待完成物細分，根據以往估算和經驗進行類比估算。 對以往估算和經驗的處理，可以分為兩種做法：
1，不做特別處理，自然停留在團隊成員的頭腦里，使用時其實不明確要求、不保證能夠想起來對比
2，記錄典型事物（特性，用戶故事等）所需要的工作量，得到1套基準類比庫，新任務根據這個基準類比庫來估算。
在使用理想工作量的情況下，需要1個名為capacity的參數。工作量 = 理想工作量 / capacity ，capacity的取值1般是50% ~ 80%。
在估算時，本次待完成的理想工作量 = 計劃的工作容量 * capacity
在回顧時，capacity = 原估算的理想工作量 / 實際工作容量 * 100%，注意工作容量其實不等于工作量，而是團隊在指定時段內可以提供的工作量，比如 5個人的團隊工作21天，那末這個工作容量就是5*21=105人天。
在使用工作量時，注意辨別毛時和凈時，在選擇凈時的情況下，需要注意1天按多少小時來計，比如按5小時來計算，估算工作量到達50工時，如果1個人做的話，需要10天來完成。
問題6，在甚么情況下使用直接工作量估算？
可以看到雖然之前也存在直接工作量估算的做法，但并沒有得到大力的宣揚，在之前的軟件工程教材里，1般很少提直接工作量估算。
從敏捷類開發方法開始起，直接工作量估算得到了宣揚，得到了更廣泛的傳播。
在敏捷類軟件迭代開發當中存在對此方法的很多利用。
問題7，Story Point的特殊情況是甚么？
Story Point的起源與理想工作日緊密相干，1般的，在開始時，團隊會將估計1理想人日能完成的用戶故事為1個故事點。
如果始終保持1理想人日對等于1個故事點，那末故事點估算實際上是直接工作量估算。
但多數情況下，1個故事點對應的工作量是會產生變化的，隨著團隊的變化，對1個故事點所需要的工作量1般會減少。
有些團隊會始終保護1套用戶故事樣例庫，相當于用戶故事的砝碼，新的用戶故事與樣例庫的用戶故事進行比對，進而判定新用戶故事的故事點數。
在具體比對上，常見的方法有 排序法，排序法1般利用斐波那契數列（1，2，3，5，8，15, …，？，無窮大），還有模仿T-shirt size估算，常見的，分成3到5檔，比如 S、M、L、XL，或大、中、小，給每檔設定故事點數值。
可以看到排序法和T-shirt size模仿估算在本質上是1樣的，T-shirt size模仿估算是排序法的1個實現。
這有樣例庫的做法得到的估算點數就是范圍，值得注意的是 故事點所表達的范圍是相對的范圍。不同組織、不同團隊的故事點是不可以比較的。這與諸如IFPUG、NESMA等等的功能點是不1樣的。
4個國際軟件功能范圍丈量標準的功能點是像“米”1樣的絕對單位。就是說 在中國A公司的A1軟件用IFPUG辨認出了1000個功能點，美國B公司的B1軟件也用IFPUG辨認出的1000個功能點，那末可以說A1軟件的范圍與B1軟件范圍相等。而如果中國A公司的A2軟件用Story Point辨認出了1000個故事點，美國B公司的B2軟件也用Story Point辨認出了1000個故事點，那末，是不能說A2軟件的范圍與B2軟件范圍相等，兩種不具有可比性，如果非要比較，那末需要分析A2和B2各自所根據的故事點樣例或基準。
前面說到新的用戶故事與樣例庫的用戶故事進行比對，進而判定新用戶故事的故事點數，目前這個比對并沒有絕對的做法，常見不同的做法有：
1，是不是斟酌不同人做的影響
2，是不是斟酌實現的復雜度、難度
3，是不是斟酌新用戶故事關聯或依賴的事務
4，是不是斟酌有疑問的部份
目前業界對以上的問題并沒有定論，各家組織或團隊結合各自情況和理解各有各的選擇。
因此，Story point具有在范圍和直接工作量的兩種形態之間變化的多態，具有巨大的靈活性，具體組織在采取Story Point時，可以做適應性的選擇。
問題8，哪一種方法更加準確？
沒有結合具體情況，這個問題是沒法回答的。
假定誤差系數= 估算值/實際值。
估算值 = 實際值 * 誤差系數
絕對誤差 = 實際值-估算值 = 實際值 - 實際值 * 誤差系數 = 實際值*（1-誤差系數）
可以看到的1點是 敏捷小團隊短迭代的實際值是不大的。 假定9個人的團隊，迭代周期是3周，那末 實際值約在135人天范圍以內。就算誤差系數比較大，絕對誤差也是有限的。
而傳統瀑布型項目就是另外1個模樣，比如時間跨度或許到達1年，總的人月數約是120人月，在這類情況下，就不難理解為何存在多個組織來保護功能點定義，搜集數據，給出需要指數運算的估算公式。由于就算誤差系數小，由于基數大，所釀成的絕對誤差就比較大。
在敏捷開發方法里，常見的，采取撲克估算方式，這個方法可以驅動整體團隊的智慧來肯定故事點的大小，也能提高估算的精確度，而且也能澄清不同的理解，是非常值得采用的1個方法。
