How to Choose a Software Sizing Method That Works With Your Data

So, you're ready to estimate the size of a planned software development project or capture the actual size of an in-progress or completed project. The good news is SLIM-Suite® tools are incredibly flexible. You can model almost any software development lifecycle methodology and choose from a wide variety of size metrics and techniques. The bad news is, with so many components and sizing methods to choose from, how do you select the right one for your project?

Watch Episode 4: Choosing a Sizing Method

Episode 4 of our video series, Software Size Matters: Why Quantifying Software Size is Critical for Project Estimating, Tracking and Forecasting, and Performance Benchmarking, focuses on choosing a sizing method that fits the information you have on hand and your project's lifecycle stage. In previous videos, we discussed why quantifying software size is important, what software size is and is not, and looked at familiar metrics you're probably using now. It turns out there are a variety of sizing methods to choose from. Asking a few simple questions up front can quickly point you in the right direction.

What do you know right now? If it's early in the project, you have a general idea of what has to be built, tested and delivered, but the detailed requirements aren't available yet. So, there's little point in choosing a requirements-based sizing method like Requirements, Function Points, or even User Stories, because there's simply nothing to count yet. If, on the other hand, high level or detailed requirements are complete, a requirements-based method makes perfect sense. The data on hand matches the data needed to perform this kind of size estimate. The prudent thing to do is choose a size method that's supported by the data you have.

The biggest challenge to software estimation is uncertainty. You must produce an estimate when you know very little about the scope. The amount of data you have is tied to the lifecycle stage of your project. As you progress through the lifecycle timeline, more information becomes available:

​

1. During Concept Definition, little is known. Use a Rough Order of Magnitude (ROM) method, namely T-shirt sizing or sizing by analogy. We have a client who maintains a list of historical projects with T-shirt sizes. Estimators look for historical projects similar to the one they need to estimate to determine the t-shirt size for the new project.
2. During Requirements and High-Level Design, single components such as requirements, features, user stories or technical requirements are available.
3. During Development and Test, discrete testable parts of the software system emerge. There are multiple components, like the RICEF objects often used to estimate commercial off-the-shelf packages and technical measures like modules or source lines of code.
4. During Maintenance, you're dealing with problem reports, enhancement requests, patches, and source lines of code.

Notice that when the project is complete, there are several options for collecting the actual software size for measuring productivity and other benchmark metrics.

This list of common software size estimation techniques is ranked by the amount of data needed to use them from least to most.

​

• Sizing by Analogy and T-shirt Sizing.
• Single Component, High Level. This is where one function unit like function points is used to measure the entire system.
• Single Component, Detailed enables you to capture complexity if you have enough information to identify small, medium and large user stories or similar function units.
• Multiple Components are identifiable components or layers of the system that may be countable.
• Code Counts. These are helpful for cloud migration and other project types.

Let's look at a few examples.

​

• Relative Percentage. Use this technique to generate an early estimate of the total system size relative to a single component you know or have already estimated the size of. For example, Component A is 20,000 source lines of code and comprises 10% of the overall functionality. Component B is twice the size of Component A, therefore 20%, and Component C is roughly half the size of component A, equaling 5% of the system. This initial rough order of magnitude estimate can be refined as the as the design progresses.
• PERT, which stands for Program Evaluation and Review Technique, is commonly used to estimate project task effort, but can be applied to software size estimation. You provide a range of inputs, low, most likely and high for each component. Typically, the range is not symmetrical. That is, the difference between low and most likely and high and most likely are not the same. You calculate the average, giving the most weight to the most likely. The formula can be adjusted to use different weights.
• Delphi. This method employs a diverse group of experts, or team members in Agile development, to produce more accurate software estimates by including diverse perspectives and experiences. The games are played until there is a consensus among the team members. These methods can't be used until user stories have been defined and often use the Fibonacci Sequence to assign story point values.
  • In Planning Poker, each team member chooses a user story card, estimates the size, then all the cards are played and discussed.
  • The name White Elephant comes from the group gift exchange game, also known as Yankee Swap. In place of gifts, the team has stories. Once a member has estimated the first user story, each team member has the option to assign a value to that next story, move a story already played to another level, or pass.

To summarize:

• There is a variety of sizing techniques and methods to choose from.
• Software size estimation is particularly challenging because you have to produce an estimate when you know very little about the scope. The amount of data you have is tied to the lifecycle stage of your project. Start with T-shirt sizing, then use more methods as you progress through the project lifecycle.
• Agile development has increased the awareness and use of software size measures once the product backlog takes shape.
• And you can reduce uncertainty by using PERT and Delphi methods.