We take a look at the various ways to measure software size

Software sizing is not easy, because there are hundreds of languages, architectures and techniques for writing it.  The industry has tried many different approaches over the years, but the most effective is an approach called functional sizing.   Knowing the size is generally most useful before the code is written. Size can also be an indicator of the amount of business functionality involved.  Techniques such as counting user stories, counting story points and the leading function point analysis methods: COSMIC function points and traditional (IFPUG) function points are all discussed here.  It is also possible to assess size after the code has been written, this is generally less useful.

Straight to the point: we recommend that you use COSMIC Function points in most instances.  Why? because they are valid, reliable, consistent, ungameable, quick to measure and suited to Agile work where the full requirements may not be known up front.

Why does software sizing matter?

Developing software is labour-intensive, knowledge work.  The biggest cost driver for developing software is usually the human effort to create it, design it and test it.   What we generally want to know is how much effort and how much time will it take to deliver.  There are many factors that affect the time and effort.  The most significant factor is software size.  So let us look at the various approaches to sizing software.  Often we confuse sizing with effort estimation.  For instance story points and t-shirt sizing is really just effort estimation, not sizing.

Lines of Code

Lines of code is easily and automatically done by most coding tools.  There are two main values, the gross number of lines used (LOC) and the net number of lines of functional code (SLOC).

Counting lines of code has limited merit in software project management.   Consider for example two developers who both write 50 lines of code in a day.  It could be that one of the developers writes terse, efficient code that makes good use of underlying language capability.  His 50 lines good deliver significant functionality, possibly even an entire (tiny) application, where as the other might just perform a very basic validation.  Superficially these  are as productive as each other, both writing 50 lines per day.    This is the main reason that we limit the use of SLOC for software sizing. FAST, INCONSISTENT, MISLEADING

Counting Stories

Many people are of the opinion that just counting the number of stories is as good as anything.  This is an unreliable approach as some user stories are significant development undertakings, we might really call them epics, whereas other user stories are so trivial as to involve no user recognisable functionality at all.  The range that we typically see is 0 – 120 CFP.  As you can see, we are using the COSMIC sizing methodology to validate whether other approaches have merit. FAST, INCONSISTENT, MISLEADING

Counting Story Points

Story points are an arbitrary proxy for size measurement that should only ever be used within a team.  They are not a valid measure nor metric for determining progress against team.  Remember that story points can change over time, and are an inconsistent opinion of the duration likely for some activity to take.  They are highly game-able by those providing the count.   The popularity of story points is a somewhat bizarre behaviour of the majority of the software industry – their popularity is not merited.  On the other hand, COSMIC Sizing and IFPUG Sizing are both formal, consistent ISO standards for measuring size.

A user story can vary in size dramatically.  One story can be delivered in minutes another can require an entire team to work for a month.  Counting stories of different size is an indication of progress but is not a valid measure of progress.  SLOW, INCONSISTENT, MISLEADING

Function point sizing automated by ScopeMater is a ground-breaking approach to bringing certainty to software projects

How does Function Points Sizing Help?

The most significant cost driver on software is effort (human work involved in specifying, designing, developing and testing) software.  The best forward indicator of the amount of effort needed, is size, specifically the size in function points .  If you know the size, you can predict the effort.  You can actually predict, with confidence, the staffing needed, the time that will be needed and even down to how many defects you need to find and fix.  This predictability helps managers plan effectively.  Of course there will be some unknowns but not as many as most would claim.

Different Ways to Size Software


  • COSMIC Function Points
  • IFPUG Function Points

Can be useful:

  • Object count
  • Lines of code
  • Count DB tables
  • Count OO classes

Not recommended:

  • Story points
  • Count stories
  • T-shirt sizes

Function Points Analysis

ISO standard Functional Sizing

The only consistent way of measuring software size (as of 2023) is functional sizing.  There are two leading standards for functional sizing:   IFPUG Function Points (1st Generation) and  COSMIC Function Points Points (2nd Generation).

Both Function Point standards are mature, valid and proven (IFPUG:1974,  COSMIC:1998)  They are a consistent, user-centric description and measure of functionality in terms of inputs and outputs and data stored.   They are counted by examining the requirements, and applying some rules/principles to determine the data types that are moved and stored.  Both standards are mature, independently maintained and free or inexpensive to learn.  We recommend the 2nd Generation COSMIC Sizing methodology.  The units of the COSMIC sizing methodology are the COSMIC Function Point (CFP).  The work to perform the function point sizing is called function point analysis (FPA).

Cosmic and ifpug software measurement standards for Function Point sizing


Some of the key benefits of the COSMIC FP standard are:

  1. COSMIC Sizing is based on principles of software design.  As a standard, no tuning is needed when applied to different types of software (custom coding, middleware, web apps, multi-layered software, system software, embedded systems or data warehouse projects).
  2. COSMIC gives us a definition of a single function point,  each movement of a data group Entry, Exit, Read, Write counts as 1 CFP.
  3. CFP can be accurately measured from incomplete requirements which makes them suited to Agile and various forms of scaled Agile work.
  4. CFP are faster and easier to learn than IFPUG FP.  (1/3 of the number pages for the entire methodology syllabus)
  5. COSMIC FP can be determined automatically to a higher degree of precision than IFPUG via automated requirements analysis.

To learn more about COSMIC Sizing we recommend The Guide to Software Sizing by Charles Symons

IFPUG Function Points

Having said that COSMIC FP are preferable over traditional IFPUG FP, the latter benefits from larger volumes of published and available benchmark data.  The IFPUG  sizing methodology was designed in the 1970’s when software design was less layered and segregated that it is nowadays.   The standards remains largely unchanged from its initial concept.  We like IFPUG FP, but we prefer COSMIC FP.  Simple Function Points is an approximation of IFPUG FP adopted by the organisation in 2019.  ScopeMaster estimates both IFPUG and Simple FP.

Counting Function Points Manually

Up until now, counting function points has been a laborious manual process  You need to read the requirements and then record the function point counts on paper, or in a spreadsheet.  Accurate and consistent counts are achieved only if the count is performed by certified and experienced function point specialist.  On average a certified measurer can measure up to 2000 FP/ week,  this is the equivalent of about $2m worth of software.  SLOW, ACCURATE

Estimating Function Point Size

Using some rules of thumb, estimated FP counts can be achieved by looking at a number of contributory factors.  If your application is predominantly a database type application, you can count the number of database tables of data being maintained by the application.  You then multiply the number of tables by 27-30 for an IFPUG estimation.  This is just one of many useful rules of thumb and should be not be relied upon for anything but a high level size.  Counting speed: 5,000 – 50,000 FP / person week  FAST, INACCURATE

Backfiring Function Points from Lines of Code

Most software language have published averages for lines of code per function point.  For example 50 lines of Java is, on average, equivalent to one function point.   Counting the lines of code and dividing by this number is called “backfiring”.  This is useful after the code has been written.   You need to be careful with this approach especially when using large volumes of pre-written frameworks which may need to be excluded from a custom code count. Counting speed: up to 5,000 FP / person week.  FAST, INACCURATE, MISLEADING

Automated Function Point Count from Code

It is now possible to automate function point counting from code.  The  Cast Software company have developed software that will perform a reliable Automated Function Point count based on existing application code.  It takes some effort to prepare the code so that it can be interpreted, thereafter a reliable count can be achieved. This is far superior to the backfiring approach.  It has the added benefit of providing deep insight into the application code.   FAST, CONSISTENT, ACCURATE

Automated COSMIC Function Point Sizing

Using ScopeMaster® you can benefit from an automated COSMIC function point count within a matter of minutes.  By analysing the text of the user requirements, we can detect the functional size (data movements).   ScopeMaster® will provide a consistent result with an accuracy in excess of 85% compared with a manual count by an expert measurer.

The results are consistent and transparent.  Combined with a manual check by a function point specialist, we see counting rates of 10,000 – 20,000 FP / per man week. (approximately $10- $20m of software) FAST, CONSISTENT, FAIRLY ACCURATE

function points information generated by ScopeMaster®

Some of the sizing analysis that ScopeMaster® generates automatically from your written user stories.


If you want to determine the size of an application from the written requirements you have two main choices: count function points manually or use ScopeMaster® to count them for you.  If you already have application code that you want to measure, then there are additional choices: backfire from the lines of code, estimate from technical components (e.g. based on a database table count), or look at the automation of functional sizing from CAST Software.