Software Sizing and specifically agile software sizing is difficult and notoriously unreliable.  Yet having reliable estimates is essential for sound investment decisions and effective planning.

Managers and executives are constantly faced with difficult decisions about software work.  On larger projects, budgets and schedules are frequently exceeded, both of which lead to considerable waste and inefficiencies.   Managers need to know the likely cost and duration to develop software so that they can plan accordingly.  They are expected to make dependable decisions about priority and resource allocation and yet often do so without reliable estimates for the time and needed.   Reliable estimates are very valuable.

Most software professionals believe that it is impossible to estimate software development work, or that it is too time consuming to even try.  This is not so.

Reliable Software Sizing is Possible – and it’s not so hard either.

Estimates from the technical teams are usually underestimates.  They almost always underestimate the time and effort actually required.  It is human nature to do so.   Developers often resist offering estimates at all, in case their estimates might be treated as commitments.

It is incumbent on the industry to get better software (effort) estimation.  Only this way can wasteful delays and overspends be avoided.

Where to start?

As many as 60 factors  can affect the time and effort to develop software (such as complexity, work environment, executive support, technical experience, requirements volatility).  The single most significant factor is size,  specifically functional size. (put your story points to one side just for now, as they are not a measure of size but a pseudo effort guess).

Estimate Software Functional Size First

Once you know the functional size, you can quickly derive related estimates for other dimensions, such as:

  • resources needed
  • costs
  • time to develop
  • tests needed to achieve suitable quality

What is Functional Size?

Functional Size, or Functional size measurement (FSM) is a mature and proven technique for sizing software functionality.   It is agnostic of the technology and development methodology.   Functional size is a universal measure that applies to all types of software.  It is considered from the users perspective.   It is objective and valid, and consistent.  Two people measuring  the functional size should come up with the same number each time.   The unit of measure is the function point, specifically the COSMIC function point or CFP.  The CFP can be estimated or counted (exactly) just from requirement  and specifications.  The functional size is independent of the coding language used to develop it.  FSM has been around for many years and has proven to be the most reliable measure of software size.  FSM allows you to estimate or measure size before, during and after the code has been written.

What about story points?

Story points are essentially a proxy for effort estimates.  Story points are a team based opinion about the amount of effort it might take to build some software, a developer’s perspective.  They are highly subjective and dependent on the opinions of the team.  Story points are a helpful means of communicating within the team about how hard something might be to do.  But that’s all.

Does it take long to learn?

You can learn to size software (properly using a functional sizing standard) in a couple of days or less.  You can become fully proficient and certified in just a few weeks.  It may take longer to learn how to leverage the value of the measurement, but for that, there are experienced advisors.   ScopeMaster does most of the work for you!

Automated Software Sizing with ScopeMaster

ScopeMaster is the first and only tool to reliably estimate functional size directly and automatically from written requirements.  Don’t just take our word for it though, experts and academics around the world agree:  Academic validation of ScopeMaster as an automated sizing tool.

Bring Certainty to your software work with automated functional size measurement.

For more on COSMIC functional size measurement, visit

The great thing about knowing the size up front, is that you can allocate the correct amount of time and funds to any software endeavour.  Just knowing the size can usually save you 10% or more on a larger software project, often more.

If you want to get started with effective and rapid software estimation, use ScopeMaster to estimate the COSMIC function points directly and instantly from your requirements or user stories.

ScopeMaster was conceived as a tool to automate the clerical work of measuring the functional size of software from requirements.  “The reason I set out to write a tool to do this is because, as a software project manager, I found that functional size is the single most significant factor that I need to manage a project successfully.”

ScopeMaster interprets the functional intent of the user story or software requirement, and so is able to automate functional sizing, which can then be used for further estimation of software development.

Not only is ScopeMaster much faster than measuring manually (at least 4 times faster),  it takes much of the drudgery out of doing the job.    ScopeMaster “reads”  the requirements, identifies language patterns that implicate functional need and then sizes them accordingly.  It can estimate size at about 3 CFP per second. You could size a 1000 CFP set of requirements (about $1m of outsourced software) in about 2 or 3 minutes.  You might then review the results  to a) correct any reqirements  mistakes and b) verify the functional size of each requirement.  Once verified by the analyst, the estimate becomes an exact count/measurement, which can even be used for fixed price outsourcing of software development work.,

COSMIC Functional Sizing

Over the years, several variations of functional size metric have been created.  Only five have achieved ISO recognition (COSMIC, IFPUG, Mark II, NESMA and FiSMA).  IFPUG, Mark II, NESMA and FiSMA are all similar in that they are derived from the original ruleset created by Allan Albrecht at IBM back in the 1980’s.   The COSMIC functional size methodology evolved from earlier methodologies, specifically designed to address the shortcomings of them.  The key advantages that make COSMIC more relevant to modern software are:

  1. COSMIC FSM is designed to handle interconnected software layers – suited to modern software architectures.
  2. COSMIC measurements can be made before all requirements are known – highly suited to Agile development.
  3. COSMIC FSM is principle (not rules) based – easy to learn

Function Points and Story Points

Story points are prevalent across all Agile projects, they are a team-specific proxy measure for effort.  By this, I mean that each team has a common understanding of the magnitude of a story point, it is typically in the order of a few hours of effort, but there are no strict rules.  I saw one organisation that had 6 teams each of which had a different understanding of the size of a story point.  Story points are not a universal currency, they are not a standard, they cannot reliably be used to compare teams or projects.  Story points are a useful internal indicator of anticipated effort.  Function points however are universal, standard and highly applicable to Agile development as much as any other development methodology. I advocate, continue with story points at the team level, but use function points for everything else.  For more on the merits of CFP vs Story Points

Size is the cornerstone of Software Estimation

Once you know the functional size in COSMIC function points (CFP), you can quickly establish other metrics that are directly related to size, such as cost, effort and schedule.  Once the size in CFP is established you can then use industry conversion values that map function points to effort, cost and schedule.  Rather than use industry conversions, you can use your own historical project data to establish your own benchmarks.

What can you estimates based on size

  • Schedule (number of months needed to deliver)
  • Cost (total cost to design, develop, test and deliver)
  • Effort / Resources  (effort needed to design, develop, test and deliver)
  • Quality  (defect potentials for each constituent of the delivery)

How fast can you derive estimates

Manually, a competent analyst can count (measure) function points at a rate of about 100-500 FP per day (approx $100k – $500k of software).  This depends on the quality and clarity of the requirements and specifications.    The speed also depend on the experience and ability of the analyst.  With ScopeMaster you can expect to achieve these rules about 4 times faster.


Take a few past projects, insert their requirements into ScopeMaster to get the functional size.  Given that you (should) know the cost, effort and schedule of those projects.  You can then use that data to predict the next project, simple, easy and fast.

Benchmarking Software Productivity

Size is not the only factor that affects estimation accuracy,  but it is the most significant one.

For those who consider estimation to be harmful, unimportant or just too difficult, check out Steve Mconnell’s excellent article on the subject of why estimation is an important and valuable skill that project managers need.