If you’re a SLIM user, you probably know that a function unit such as story points must be assigned a gearing factor to normalize the size for the statistical computations that SLIM performs.  If you’re using story points as your function unit, what gearing factor should you use?  There is no single right answer, for several reasons.

First, if you’ve followed the suggestions we’ve outlined in the previous articles and have consistent bins, exemplar stories or epics for each bin and the bins are calibrated based on the story points assigned to historical projects, you can get consistent enough sizing in story points from project to project within your organization.  However, that doesn’t mean that your bins and story points are consistent with other organizations, and the gearing factor you use may need to be different from other organizations.

Second, the gearing factor you use depends on aspects of how you use SLIM.  Some SLIM customers primarily use the QSM trend data that’s delivered with SLIM, and base their estimates on the industry‑wide data found in the QSM database of projects, from which those trends are derived.  Other SLIM customers primarily use their own historical data and compute custom trends.

Third, the gearing factor you use depends on how you capture historical size of your completed projects, and what sizing unit you use for that, which may be different from story points.  SLIM‑DataManager allows you to capture size of completed projects in multiple ways, using the technique called “secondary sizing units.”  You may use story points as a secondary sizing unit for historical projects, and the primary unit for new estimates.

The gearing factors you use depend on these choices and more.  The specifics of all the variations are beyond the scope of this paper, but the key is that the gearing factors you use must be coordinated with the Productivity Index (PI) values you use in your SLIM estimates, typically chosen based on the trend data used for the estimate. QSM can consult with your organization to help choose the appropriate gearing factors.  Here, we’ll describe two ways to choose a gearing factor for story points that may be helpful in your organization.

Method 1: You size completed projects using a source code counter.

We discussed the use of Source Lines of Code (SLOC) for sizing agile projects you need to estimate later in the previous article in this series.  There is nothing unique to agile methods about the finished code when a project is complete, and you may be using an automated code counter to measure the size of completed projects in SLOC.   That data can be used to calibrate a gearing factor for story points.  You can use this whether you use QSM trends or you compute your own trend data.   If you are using a QSM trend, the validity of this depends on how your coding style and how the SLOC measurements your code counter computes compare with the industry standard.   If you are using SLIM-DataManager to capture your history, and optionally also use SLIM-Metrics to compute custom trends, use the code count in SLOC as the primary sizing unit for the projects you’re including in the trend computation.  In the fourth article in this series, we described the notion of “estimated actuals,” the story point counts assigned to stories that we actually included in a release.   Compute the total of these estimated actual story points for stories that were included in the release and enter that into SLIM-DataManager as a Secondary Sizing Unit.  SLIM-DataManager will compute the gearing factor for story points on each project.  Since these “estimated actuals” still have variation from project to project, the gearing factors won’t be exactly the same for each project; you will get a distribution of gearing factors.  The median of those gearing factors will be a good choice for the gearing factor for new projects to go along with the QSM or custom trend and the PI values you use derived from that trend.

Method 2: Story points are your main measure of size.  You compute your own trend data for estimates and you do not need to compare your projects to industry data. 

The details of how to compute custom trends and which projects to include are beyond the scope of this paper. In this situation, the gearing factor you use can be almost arbitrary, but you must use that same gearing factor when computing the trends and with new estimates, and you must use those trends and the PI values from the trends as the basis of the choice of PI in new estimates.  For example, you could use the PI Calculator in SLIM-Estimate to choose the PI for a project, since that will be based on the trend used in the project.

For technical reasons beyond the scope of this paper, the SLIM methods require normalized sizes of projects in the thousands.  This is the main restriction on how you choose the gearing factor for story points. When you enter completed projects in SLIM-DataManager that you will use as input to SLIM-Metrics for computing trends, use story points as the primary function unit.  Enter the total “estimated actuals” for stories included in the release as the size.   Choose a gearing factor so that the size in Implementation Units (IU, the base unit that SLIM uses to normalize size) is in the thousands, or even 100’s of thousands if it’s a very large project.   Choose the same gearing factor for all your projects, and also use this gearing factor for new projects.  By using the same gearing factor for the historical projects that went into your trends and also for new estimates, and by using the PI values based on those same trends for the new estimates, the PI values and normalized sizes are matched as required by the SLIM methodology. However, the normalized sizes of your projects, based on the arbitrary choice of the gearing factor, may not be comparable to the normalized sizes of the industry data in the QSM database.  You should be aware of that when asking QSM for information from that database.