软件项目工作量估算从估算根据上看可以分成以下两类：
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个方法。