Story Points Explained

Story points come out of the “agile” family of software development practices. They allow a software development team to accurately estimate and manage projects.

Story points allow a team to estimate the size of a software project in relative terms. For example, if feature A is worth three story points and feature B is worth six, we expect feature B to take about twice as long as feature A. We don’t know, exactly how much time or effort either feature will take, though. We just know their estimated size relative to one another. However, as soon as we build feature A in eight hours, we can guess feature B needs about sixteen hours.

Many of us, though, estimate our work in hours. Doesn’t this make more sense? It’s a currency we all understand, so why aren’t they the preferred method in agile?

3 Keys to Software Projects

To see why story points make sense, let’s take a step back and look at three key concepts in estimating and managing software projects.

(If you’re already familiar with these concepts, you can skip straight to our definition of story points.)

Size

How big is a software project? The software industry has experimented with many ways of measuring size: lines of code, for example, or the metric known as “function points”. Unlike the size of a physical object, software size is difficult to measure. You can measure a building in square feet, or a highway in miles, but there’s no universal measurement for a software project.

Time

How long, in calendar terms, will the software take to build? This is strictly a measurement of the interval between the project start date and the software delivery date.

Effort

How many person-hours (or person-days or weeks) will the software take to build? This is separate from the question of calendar time/duration. A project may take six months to deliver. However, if your team consists of three people, your effort is lower than if the team size is six or ten people working for the same amount of time. Effort is important because it is usually the primary driver of cost, inasmuch as we need to pay the people doing the work.

The Typical Process

A normal estimation procedure, for estimating any kind of work goes like this:

1. Estimate the project size
2. Carefully consider and estimate the effort required to execute work of that size
3. Based on resources and schedules, estimate the calendar time that this effort will require

Step two is important, because it allows for calibration. As you gather project information from your organization over time, you come to know that X units of size take on average Y time to build. If you’re a builder, you may know that your teams can average 8 square feet of finished construction per person-day.

When you need to estimate schedule and effort for a 2400-square-foot house, you can expect it to take about 150 person-days. However, in order for calibration to be possible, you must separate your size estimate from your effort estimate.

Velocity in Estimation

To think about this from another angle, let’s take a look at the key idea of velocity. This is a powerful concept from the world of agile estimation. (Although it has strong analogues in the “traditional” project management discipline of earned-value management.)

Before looking at velocity in software, let’s look at its typical meaning. If you’re taking a car trip, velocity is expressed in miles or kilometers per hour, or, units of distance per unit of time. Put more simply, v = d/t.

When you’re traveling, you can use velocity to estimate your arrival. Suppose you have a 500-mile trip to take, and after three hours you’ve traveled a total of 175 miles. Your average velocity so far is 58.33 mph. If this remains your average velocity over the entire trip, the trip will take 8.57 hours, so you have 5.57 hours remaining.

Notice that to do this, you need to be able to measure BOTH distance AND time. Of course, sometimes, we “cheat” and collapse the two, and when someone asks us how long the trip is, we answer “it’s an eight- or nine-hour trip.” Well, whether it’s really an eight- or nine-hour trip or not depends a lot on conditions, vehicle etc, so it’s an imprecise answer. If we said it was a 500-mile trip, that would be a precise answer.

Velocity of Story Points

You can use the same technique to estimate effort and duration of a software project, once the work has proceeded a ways. Suppose, without worrying about just what a story point “is” for now, that you’ve decided your project comprises 400 story points. You work for a month (duration), and the team completes 60 story points, using 450 hours of effort. From this, you learn that your team’s velocity is 13 story points per person-hour, and that the team will thus likely require 3000 person-hours of effort to complete the work.

In addition to this “effort velocity” you can (and should) also compute a duration velocity: the team completed 60 story points in 20 work days, leading to a velocity of three story points per work day. So you can expect the work to take about 134 business days (rounding up).

Traditional velocity, remember, is units of distance over units of time. Software velocity is measured in units of software size over units of time. (Distance is of course just the size measure of a trip). In particular, you have an effort velocity, which is units of size per person-hour, and a duration velocity, which is units of size per workday (or week or however you wish to measure).

What’s indispensable to all of these calculations is a size measure. You have to have that numerator.

Story Points, Explained

Fine, you say, but what IS a story point? What does it correspond to, really? I know what a mile of distance is. A story point isn’t anything.

Well actually, if you know how long a trip is and you have an odometer to tell you how far you’ve come, you don’t need to know what a mile is. Suppose instead of miles your trip were measured in furlongs, and your car’s odometer measured furlongs as well. If you have access to the total distance (in furlongs) and the odometer reading (furlongs again), you don’t need to know anything about what a furlong “really” is. You just need to know how many miles make up the entire trip and how many you’ve traveled so far.

The Problem with Estimating with Hours

In truth, it’s perfectly possible to figure out velocity using estimates based in hours. This is more or less what earned-value management does. Say you have a body of work you’ve estimated at 400 hours. But the first twenty percent of the work takes 100 hours. As a result, you can expect the entire project to take 500 hours, not 400. Your velocity, if you want to measure it, it is 0.8. But 0.8 what? Well, you end up with a ratio, as usual, of your size measure, which is hours, and your effort measure, which is … also hours. So your velocity is measured in something like “estimated hours per actual hour worked.” Or more succinctly, hours per hour.

Now there’s nothing wrong with this, if you can handle the slight mental gymnastics involved. It seems a bit odd to make one unit (hours) work for two different things (size and effort), and end up with a velocity measured in “hours per hour.” But earned-value project managers navigate this equation all the time, and the world still spins.

Another thing about hours, though, is that they already mean something other than a measure of software size. In database design, to digress for a moment, you should never create unique database identifiers from real-world data. In other words, don’t uniquely identify people through their Social Security Number or their address, because those are things that have real-world significance. Their semantics and use could change, affecting your technical design. Make up your very own identifier that’s deliberately meaningless, and you can be sure there will be no confusion with real data.

Something similar can apply in using “hours” to estimate software size. Since hours already mean something, it’s easy to get sidetracked into discussions like this one: “I don’t see how you can estimate that report at eight hours. If you know what you’re doing, it should only take four.” At this point, size and effort are getting jumbled together. Notice that the dangerous “should” is creeping in there as well. I can’t count the number of conversations I’ve had over the years in which someone looks at an estimate and says “but it shouldn’t take that long!”

Estimating Better with Story Points

Estimation, in theory, is an empirical discipline: it means applying a known algorithm to known data. The result is only empirical within the limits of the algorithms — it carries considerable uncertainty, and may be dead wrong. But in theory, to estimate, you take some inputs, run them through a known process, and get some outputs. If you consistently get poor estimates, this means that either your inputs or your estimation algorithms, or both, are in need of improvement.

Either way, “should” doesn’t belong in the equation. Social pressure to skew estimates toward what they “should” be is a major issue in software project management. Anything that discourages this natural tendency is a good thing for your team. Hours estimation is tied to very personal ideas about one’s own skill and productivity, as well as those of one’s peers or employees. By contrast, I don’t think anyone is going to argue vehemently that a story “should be thirteen story points, not eight!”

Potential Issues with Story Points

None of this is to say that story points are without any issues of their own. One issue is the question of “historical velocity.” Over time, as you estimate, you can get a sense for how long things take. After analyzing a number of past projects, you may discover your team averages 4.5 hours per story point. This is the key data that will enable you to take new estimates in story points (estimates of size) and turn them into estimates of effort.

Apples to Apples Comparisons

The catch with using historical data is that there must be some sort of apples-to-apples comparison for the data to be most useful. Ideally, the projects should be similar in three areas:

1. Software type: (Comparing estimates on firmware for an embedded hardware controller with estimates for a website is probably not useful).
2. Software size: Industry data shows clearly that software projects of different sizes perform differently, with diseconomies of scale in some areas. A project of five person-years will require a higher percentage of communication and project management than one of five person-months. Note that I did say a higher percentage, not just a higher amount.
3. Personnel: The best historical data for predicting the future performance of a specific group of people is data they themselves generated.

Consider Your Resources

Let’s assume that your organization tends to build the same kinds of software, within a similar size range. That leaves us with the issue of people. If you have a setup of consistent teams, each can develop its own historical data. For example, team A tends to run at 4.5 hours per story point, but team B runs at 5.4.

But if your teams are fluid, you may want to do a little more work. Of course, you can just aggregate all the team data together and build uo=p the organization’s historical data over time. Gather a good bit of data and make sure you’re averaging the work of numerous people and teams together. It may take a bit longer to get representative data.

Defining Story Points

You may also want to prime the pump a bit by making some sort of pre-preemptive effort to say roughly how big a story point is. Then you can create some degree of consensus across the teams. Put your heads together and create a chart to show “three story points equals a report with up to ten columns and two levels of summary, OR a database table of up to fifty fields, OR a Java class of up to fifteen methods,” etc. Create some kind of initial baseline to provide rough comparability across teams as your team estimates in story points.

Let’s sum up. Story points allow us to make that crucial separation between estimates of size and estimates of effort. This allows us to separate questions like “how big is it?” from questions of “how long will it take, how long ‘should’ it take, and how much will it cost?” By unblurring these lines, we can provide more accurate and realistic software estimations that we can commit to. As a result, we can provide better management over our projects, work for our clients, and success for their business.

Further Reading on Story Points

• How Do Story Points Relate to Hours?
• Stop Using Story Points (a contrary point of view)