Software size is the single biggest determinant of effort and cost on a software project. When you determine the likely size of the project, you will find yourself making better, data-driven decisions, which in turn lead to greater success rates.
software estimation - automated
Consistent software sizing can help all aspects of software portfolio management
Software estimation—and specifically Agile software estimation—is thought to be difficult and notoriously unreliable, yet reliable estimates are essential for sound investment decisions and effective planning.

Estimating software size (and subsequently cost and schedule) is important to give managers an understanding of how much it will cost and how long it will take. 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 staff allocation and yet often do so without reliable software estimation of the time and effort needed.

Most software professionals believe that it is impossible to estimate software development work, or that it is very time consuming. This is not necessarily the case.

Why are developer estimates unreliable?

Developers sometimes resist offering effort estimates, often because they fear that their estimates may be mistreated as commitments. They resist too much detailed sizing analysis up front in case the requirements are not implemented. Effort estimation in story points (using planning poker) is a common practice in Agile teams. But in spite of its popularity, it is a flawed approach, that is inconsistent and gameable. Story points are a helpful means of communicating within the team about how hard something might be to do, but that’s all! They are easily inconsistent, manipulated, abused, gameable, and for most purposes, meaningless.

Futhermore, developers almost always underestimate the time and effort actually required for software delivery. It is human nature to do so. They only consider known factors, but with software, there are often unknowns that cause delay. Theses are rarely permitted in technical estimation for this reason.

Poor estimation, leads to invalid project-level decisions and are often cited as one of the root causes of large project failures.

With earlier, more reliable estimates of software work, better decisions can be made and project disasters avoided.

So how do we estimate software work reliably?

Tens of 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 in determining effort or cost is size, specifically functional size. Once you know the functional size, you can quickly derive valid estimates for other dimensions, such as:

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

  • staffing
  • costs
  • development time
  • tests needed to achieve suitable quality
  • …and much, much more

What is functional size?

Functional size arises from Functional Size Measurement (FSM). It is a mature and proven standardised technique for software sizing, a formal engineering practice approved by ISO standards groups, and agnostic of technology, coding and development methodology. As universal measure that applies to all types of software, it is considered from the user’s perspective. Above all else, functional size is objective and valid, and consistent—in other words, two people measuring the functional size should come up with the same number each time. The unit of measure is the function point; to put it more specifically, it is the COSMIC function point (or CFP), which can be estimated or counted solely and precisely from requirements and specifications. FSM has been around for many years and has proven to be the most reliable measure of software size, allowing you to estimate or measure size before, during and after the coding process.

Can I learn to estimate software size quickly?

Yes, 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 the heavy lifting here, so using ScopeMaster will accelerate your learning and software estimation!

ScopeMaster is the first and only tool to reliably estimate functional size directly and automatically from a backlog of written requirements. Don’t just take our word for it, though; experts and academics around the world agree that ScopeMaster is a breakthrough automated sizing tool.

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. Together with ScopeMaster, you can bring certainty to your software work with automated functional size measurement.

For more on COSMIC functional size measurement, visit https://www.cosmic-sizing.org.

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.

software estimation - automated

Automated software estimation with ScopeMaster

ScopeMaster was conceived as a tool to automate the clerical work of measuring the functional size of software from requirements. In the words of our founder, Colin Hammond, “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 in order to manage a project successfully.”

ScopeMaster interprets the functional intent of the user story or software requirement, and thus 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, it costs substantially less than manual sizing. Certified counters are scarce, and ScopeMaster takes much of the drudgery out of doing the job. ScopeMaster “reads” the requirements, interprets the functional intent and then sizes them accordingly. It can estimate size at about three CFP per second. You could size a 1,000 CFP set of requirements (about $1m of outsourced software) in about two or three minutes. You might then review the results to correct any requirements mistakes and verify the functional size of each requirement. Once verified by the analyst, the estimate becomes an exact measurement, which can then 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 1980s. The COSMIC functional size methodology evolved from earlier methodologies, specifically designed to address their shortcomings. The key advantages that make COSMIC sizing methodology more relevant to modern software are:

  • It is based on software principles, dealing elegantly with interconnected software layers and software architectures.
  • Estimates and measurements can be made before all requirements are known, highly suited to Agile development.
  • It has been automated and thus takes negligible learning.

Story points are prevalent across all Agile projects; they are a team-specific proxy measure for effort. Each team has a common understanding of the magnitude of a story point—typically in the order of a few hours of effort—although there are no strict rules. Story points are not a universal currency; they are not a standard and cannot be reliably used to compare teams or projects. Story points are a useful internal indicator of anticipated effort when no other means of estimation are available. Function points, however, are universal, standard, and highly applicable to Agile development as much as any other development methodology. Click here to read 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. After the size in CFP is established, you can then use industry conversion values that map function points to these metrics. Rather than use industry conversions, you can use your own historical project data to establish your own velocity benchmarks.

Agile estimation

Instead of burning time by discussing story points or playing with Fibonacci cards, we feel that Agile estimation is ideally achieved via functional sizing with COSMIC FP. That means you can better estimate:

  • Velocity (average CFPs delivered per week)
  • Schedule (number of weeks needed to deliver)
  • Cost (total cost to design, develop, test and deliver)
  • Effort (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 measure function points at a rate of several hundred FPs per day (which translates to software worth hundreds of thousands of dollars), although it depends on the quality and clarity of the requirements and specifications. The speed also depends on the experience and ability of the analyst. With ScopeMaster, you can expect to achieve these rules about four times faster.

Automated Estimation in COSMIC Function Points

Estimating as you write user stories in Jira

Using the ScopeMaster Story Analyser for Jira, you can estimate your stories’ functional size without even leaving Jira. The text of your user story is analysed by ScopeMaster’s powerful language engine to detect the functional intent and functional size.

Estimating software size from a user perspective is achievable with sophisticated language analysis of requirements

Benchmarking with ScopeMaster

Take a few past projects and insert their requirements into ScopeMaster to get the functional size. Given that you already know the cost of that past project, you can now estimate the effort and schedule of the new project.

Size is not the only factor that determines software costs and schedule, but it is the most significant one. The best measure of size is the COSMIC function point.

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

Problems with story points

  • Inconsistent
  • Gameable
  • Nonlinear

Story points are a team-based opinion about the amount of effort it might take to build software from a developer’s perspective. Story points are essentially a proxy for effort estimates, e.g. one story point might be the equivalent of one ideal employee working for one ideal day. They are highly subjective and dependent on the opinions of the team. Additionally, they vary from team to team, and even within the same team over time. Their inconsistency and gameability renders them impractical as a reliable engineering metric.


Further reading