Part II. Estimating Size

Agile teams separate estimates of size from estimates of duration. To understand the distinction, suppose I am tasked with moving a large pile of dirt from one corner of my yard to another. I could look at the pile of dirt, assess my tools (a shovel and a wheelbarrow), and directly estimate the job at five hours. In arriving at this estimate, I bypassed any estimate of size and went directly to an estimate of duration.

Suppose instead that I look at the pile and estimate its size. Based on its dimensions, I estimate the pile to contain about 300 cubic feet of dirt. This is my estimate of the size of this project. But an estimate of size alone is not useful in this case. We want to know how long it will take to move the dirt. We need to convert the estimate of size (300 cubic feet) into an estimate of duration.

A label on my wheelbarrow says it has a capacity of 6 cubic feet. Dividing 300 cubic feet by 6 cubic feet, I decide that moving the dirt will take 50 trips with the wheelbarrow. I estimate that each trip will take 3 minutes to load the wheelbarrow, 2 minutes to walk to the other side of the yard and dump the dirt, and 1 minute to walk back with the empty wheelbarrow. Total trip time will be 6 minutes. Because I anticipate making 50 trips, my estimate of duration is 300 minutes or 5 hours.

For a software project, the process of estimating duration is shown in Figure II.1.

Figure II.1. Estimating the duration of a project begins with estimating its size.

In this part, we first look at two measures of size: story points and ideal time. We then look at techniques for estimating followed by advice on when to re-estimate. This part concludes with suggestions on how to choose between estimating in story points and estimating in ideal time.