QSM provides unparalleled support throughout the product acquisition, installation, and implementation process.
For nearly five decades, QSM has helped organizations bring data-driven discipline to software project estimation, tracking, and benchmarking. Our methodology and tools turn project complexity into measurable, defensible outcomes.
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?
Watch Episode 5: Sizing Function Units
Development methods, application types, technologies, and platforms also dictate the data available.
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: