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 Function Points and IFPUG Function Points 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 points are a means of determining the size of a piece of software

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

ISO standard Functional Sizing – aka Function Point Analysis

The only consistent way of measuring software size that exists as of 2021 is functional sizing.  There are two leading flavours:   IFPUG Function Points (1st Generation) and  COSMIC Function Points (CFP) Points (2nd Generation).

Both Function Point standards have been around for many years (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)


Some of the key benefits of the COSMIC Function Points 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 Function Points.  (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 function points are preferrable over traditional IFPUG function points, the latter benefits from larger volumes of published and available benchmark data.  IFPUG function points were 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.

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

Counting Function Points by Estimation

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 Function Point Count from Written Requirements

ScopeMaster® is the only tool available for automating analysis and function points count from written requirements.   ScopeMaster® interprets the functional intent within the language used to write the requirements or user stories.  It is not 100% accurate, but our algorithms are being continuously improved, through formal verification.   We achieve a consistent accuracy in excess of 85% compared with a manual FP count.   Dealing with the nuances of the English language, makes it quite a challenge to reach 100% accuracy.  For the most part, software professionals do not need 100% accurate function point count, 85%+ is more than adequate.  The clearer the requirements, the more accurate the count.  Given the same set of requirements ScopeMaster will always determine the same result, ie. it is 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®

This is just 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.