Modeling the Size

Modeling the size of the work as “1 Project” is obviously not very useful for estimating the duration. There are no bounds on the size of a project. What else do you know about the project that might be useful for modeling the size?

I’ve known some projects that were sized by the number of screens needed for user interaction. The user’s workflow was envisioned in terms of data provided to the program, choices made by the user, and results displayed to the user. The number of screens required to support that workflow was counted, and then treated as a proxy for the size of the application.

This makes a lot of sense for relatively simple applications, many of which are mostly a front end for manipulating data in a database. For each input screen, there is some code needed to insert or update data in the database. For each user choice, there is some code needed to do calculations based on the data. For each output screen, there is some code needed to retrieve and display the data, either from the database or from the results of the calculation. For such applications, a count of the screens makes an excellent proxy for size.

Capers Jones, in Estimating Software Costs [Jon07] recommends the use of Function Points (FP) as the gold standard for sizing software. This is a proprietary model of sizing, maintained by the International Function Point Users Group (IFPUG), that depends on counting

• inputs,
• outputs,
• queries to the system,
• logical files maintained within the system, and
• interfaces to other systems.

These inputs are combined with some weighting factors and then adjusted according to “general system characteristics,” including the perceived complexity of the processing.

This is similar to sizing by number of screens, but more complicated. There are many more sizing variables, each with their own definition to count them correctly. These attributes are combined in accord with their effect on the system size. The type of system being produced also affects the size, as not all systems are simply reading and writing a database.

Jones’ book doesn’t give instructions on how to calculate Function Points. For that, you need expensive training and access to the proprietary weighting coefficients produced by crunching the numbers on hundreds or thousands of projects. In addition, Jones notes, “It is very difficult to produce a reasonable software cost estimate prior to the completion of the requirements, which comprise the first software document with enough information to derive Function Point totals.” He then goes on to describe some rules of thumb for estimating Function Point totals prior to complete requirements, while warning that they have “a high margin of error.”

Most agile software development projects decompose the work into User Stories and use either the sum of their estimated sizes or a simple count of them to account for the size of the project. This appears at first glance to be the opposite end of the complexity spectrum from Function Points, but it’s not without problems. As noted in Chapter 3, ​Decomposition for Estimation​, this can be an overwhelming number of stories if you decompose to the level normally used for development.

Using a count of User Stories, or estimated Story Points of them, as a proxy for size runs into the same problem as Function Points. It requires a complete list of stories or requirements in order to calculate the size. If you’re doing agile software development, you don’t have a phase where you list all the User Stories at the beginning, because you’re expecting to learn and steer the project along the way. That’s a motivation for using functional chunks larger than User Stories for your model.

This, too, has disadvantages. User Stories tend to regress to a mean size, because they are small and there are many of them. When decomposing to a larger chunks, there’s less confidence that they are of similar size or that there are enough of them to make their variance negligible for estimation. Many people resort to sorting these larger stories into small, medium, and large for their sizing model.

Velocity vs. Cycle Time

People use two common ways to measure the speed at which User Stories are completed. These are velocity and cycle time. Velocity is the number of stories (or the number of Story Points) completed within a fixed timebox. It’s easy to compare one timebox with another, and the timeboxes give a natural point to notice how you’re doing. Cycle time is the average time from starting work on a story to completing it. If a team if working on multiple stories in parallel, the cycle time may be shorter than the calendar time to complete a story. While people may prefer one of these measurements over the other, they are fundamentally measuring the same thing and are comparable. Velocity is work per unit of time. Cycle time is time per unit of work. This means that they are reciprocals, though you may have to adjust for different units of measurement.

Note that these size measurements only concern themselves with code. There are often other deliverables in addition to code that will require time and effort. Capers Jones recommends cataloging all of these non-software deliverables and estimating them also. In Agile projects, it’s common to specify infrequent deliverables as if they were User Stories. The frequent deliverables, and the non-software activities associated with development, can be treated as overhead in the production of functional code. They’ll affect the apparent rate of progress without having to explicitly account for them.

Another approach to non-software deliverables is to produce them in tandem with the software. If you’re measuring size in functional User Stories, you might amortize the work of creating the user manual over all of the stories. The most honest way to do this, that is, the least likely way to fool yourself, is to write that part of the manual relating to each story at the time of implementing the story. That keeps the manual and the functionality in sync, easing the estimation and measurement of progress.