The size of your house is measured in square feet, and the bigger the size, the more time and money it will take to build. The same principle applies to software development projects. Not only do time, effort, staff cost, quality and productivity increase with software size, they increase exponentially. So, what's the best unit for quantifying software size? You're probably using one or more of these familiar function units. Which one is best for you?
In Episode 5 of our video series, Software Size Matters Why Quantifying Software Size is Critical for Project Estimating, Tracking, and Performance Benchmarking, we take a closer look at sizing function units and how to capture complexity. In previous videos, we discussed why quantifying software size is important, what software size is and is not, and how to use different sizing methods. In Episode 3, we said that the sizing method you choose is largely determined by where you are in the development lifecycle because that dictates the amount of data available. When choosing a function unit, a good question to ask is what type of work will you be performing?
Development methods, application types, technologies, and platforms also dictate the data available.
- Agile development teams usually work with capabilities, features, epics, stories, and story points.
- Waterfall development methods can use anything but typically employ requirements, function points, use cases, and similar measures.
- Cloud Migration projects can use multiple sizing function units to fit the nature of the work. Is it Lift and Shift, Refactor, or Repurchase?
- Configuring Commercial Off the Shelf (COTS) packages or SaaS systems often use business processes, configurations, RICEF (Reports, Interfaces, Conversions, Extension, Forms) objects and scripts.
- Maintenance and Enhancements teams work with change requests, bug fixes, and lines of code.
These are not rules or standards! You may be configuring a package using Agile methods, so you have options. We find that using business processes and RICEF objects is more intuitive for users and business personnel, thus facilitating communication. It may be the better choice if you're new to Agile.
Once you've identified the data you have and chosen the sizing method, it's time to give some thought to the amount of work required to build an average function unit. The function units in the figure below are not equal in the amount of work, represented by the elementary programming or configuration steps required. Clearly, a project that delivers 500 Function Points requires less work than one that delivers 500 Epics and thus less time and effort.
In earlier videos, we said we need to convert the function unit to a common baseline, called the Base Size Unit, to make meaningful project performance comparisons and use multiple size units when estimating the total system size.
The gearing factor is the number of elementary programming steps required to implement an average function unit. In this example, an average story takes 100 steps, converting the 250 story project to 25,000 Implementation Units (IU) or Source Lines of Code (SLOC) equivalents.
Thanks to Agile software development methods, this is not an entirely new concept. Teams estimate the size of user stories by assigning story points. You can take data from JIRA or other applications to trace the stories back to features and epics to compute gearing factors for those relationships. This makes early software estimating easier. You will be able to identify epics long before you have detailed data on stories or story points. SLIM-Suite® applications use this type of data so you can estimate using T-shirt sizing expressed in your chosen function unit. Although it is common to let teams determine story point ranges, the best practice is to standardize software metrics across your organization or enterprise.
Taking a little time to compute gearing factors from your completed project data will be well worth it. As this example shows, you can look at the relative size of known user stories measured in story points and define size bins for epics. A small epic is 50 to 100 story points, a medium epic is 101 to 200 and so on.
To summarize:
- Development methods, application types, and platforms influence your choice of function unit. There is a wide array of function units you can choose from, and you can choose multiple function units.
- Normalizing software size to a common Base Size Unit allows you to compare past performance and sanity check estimates against your history or the QSM industry database.
- Gearing factors capture the relative size and complexity of different function units and can easily be calculated from your completed project data by counting the number of epics, stories, story points, and ultimately source lines of code that were actually delivered.
- This process is not just for agile methods. It works for requirements, data transformations, application interfaces, change requests and other function units.