One of the main properties of agile methodologies is that they offer ways to handle the uncertainty that’s an intrinsic part of software development. This goal permeates every aspect of most agile methodologies, including planning and estimating, and that’s how we get into story points estimation.
The idea that the estimation itself isn’t exact is baked into story points. Thus, story points allow teams to estimate the difficulty of implementing user stories in an “abstract,” relative way. Precisely because of that, points can’t—and shouldn’t—be used to predict or estimate when the team will deliver certain features. What are they good for then?
That’s what we’ll cover today. In this post, you’ll learn the definition of story points, what they’re good for, and some of the main pitfalls you must be aware of. Let’s dig in.
What Are Story Points?
Story points express how hard it is to complete a task or user story in agile. The team does that by assigning a numerical value to each story: the higher the value, the more effort the team expects to spend on that story.
Story points have some interesting characteristics: they’re unitless and relative.
Story Points Are Unitless Metrics
By unitless, we mean they don’t have a unit of measure attached to them. If you estimate a given story at two, it’s not two minutes, two hours, two anything. That “two” means two points.
Story Points Are Relative
Also, and more importantly, the value of story points isn’t absolute, but they’re relative to each other. If a team estimates a story at two, you should expect it to be harder than a story estimated at one while being dramatically easier than another estimated at eight. The way I like to frame this is that story points are like the duration of figures in sheet music: they don’t have any value by themselves, but only in relation to the other figures.
It’s common for teams to use powers of two or the Fibonacci sequence rather than incremental integers when assigning points. Why is that so? Well, the exponential nature of those sequences makes estimating easier. For instance, it’s way easier to distinguish between five and eight than between five, six, or seven.
Points Belong to the Team
Another important property of points is that they only make sense inside the boundaries of a single team. So a given team might assign five points to a story, while another would assign it eight. That’s perfectly fine.
Story points offer a way to measure the complexity of a given user story in a relative way. If a team is starting with agile, they’ll mostly be wrong in their estimates. They’ll learn to calibrate their estimations with time, and their story points will become more accurate.
Looking at how many points the team delivered over the last few sprints, you can possibly derive a metric called agile velocity. Velocity can be a valuable metric, but it’s often abused in terrible ways. That usually happens when a team lead goes against the rule that points shouldn’t cross a team’s boundaries. More on that later.
How Do You Estimate Story Points in Agile?
You’ve just read the definition of story points and some of their properties. But how do you go about estimating with them?
Story Points Estimation Is a Team Game
For starters, bear in mind that story points estimation is a team activity. It’s not delegated to a single engineer or the product owner, or the scrum master.
During the planning meeting for the next iteration/sprint, the team will estimate the selected user stories by reaching a consensus. For each story, developers express how many points they think the story is worth. To avoid influence—of seniors over juniors, for instance—some tactic is used so developers don’t see each other’s estimates in advance.
Consensus Is the End Goal
For instance, you can count to three, and then everyone raises their hands, showing as many fingers as the points they want to express. Another alternative is using a specialized deck of cards; each developer selects a card with the number of points they wish to express and puts it on the table, facedown. At a signal, everyone reveals their cards.
The objective of this activity is to reach a consensus. So, if developers disagree, they must justify their choice and then estimate again until a consensus is reached. The discussion that happens is, by itself, beneficial.
Let’s say a developer estimates a story at one point, while another developer estimates it at eight. This is a dramatic difference, and a discussion must happen to understand the reason for this discrepancy. During the discussion, the team might find, for instance, problems in the way the story’s requirements were communicated.
Why Are Story Points Not Hours?
One question that confuses many a beginner to agile—I was certainly one of those—is simple: why use story points instead of hours? After all, we’re used to dealing with time metrics since we were children. Besides, using time-based estimation techniques would allow for better prediction of delivery dates. Right?
Time Is Developer-Contextual
Well, one of the goals of story points estimation is to reach a team consensus on how to measure the complexity/effort of stories. Time, on the other hand, is highly dependent on the individual engineer’s knowledge and experience. An experienced engineer might take half an hour to complete a task that would take a junior a couple of hours.
Estimating in Hours Is Less Precise
Estimating in hours is also less useful/precise for the simple fact that estimations are often wrong. It’s hard to guarantee that something you estimate to complete in one hour will actually be completed in one hour. However, it’s completely realistic to expect a story estimated at five points will take less time than one estimated at 21.
You Shouldn’t Use Capacity Estimation to Predict Deliveries Anyway
Finally, you shouldn’t use points to estimate project delivery. This would be an even bigger issue if we used hours for estimation—more on this in the next section.
Story Points Estimation Gone Wrong: Why You Need to Beware
Story points are a valuable tool. However, like most tools, you can abuse them in a way that harms your team morale. How does that happen?
Points Are Contextual
First, remember I said points are highly contextual; the definition of how hard one point is, for instance, only makes sense inside the boundaries of a single team.
Sometimes, team leads go against this. They use story points across teams, creating perverse incentives and hurting team morale. Here are some of the most common antipatterns:
- Using agile velocity to compare the performance of different teams
- Similarly, using agile velocity to try to predict project delivery dates
- Using velocity as a performance indicator within teams, including using it for performance reviews
Don’t Set Metrics Up for Failure
To understand why this is bad, remember Goodhart’s law, often paraphrased as follows:
When a metric becomes a target, it ceases to be a valuable metric.
If you create incentives for a team to game metrics, they’ll likely game them. Shocking, right? For instance, if velocity is used to compare performance, this will cause story point inflation: developers might start assigning more points to stories.
To sum it up, when used the wrong way, agile velocity becomes the worst possible metric for engineering teams.
Story Points Estimation: It’s Football, Not Tennis
Agile, in its essence, is about handling the uncertainty and constant change that is intrinsic to complex software projects. When it comes to estimating and planning, this often takes the form of story points estimation.
Story points are relative measurements of the complexity of user stories. Story points estimation is a team game, not a solo one. This task shouldn’t be relegated to a single person; instead, it’s the whole team’s responsibility.
As you’ve seen, story points can also lead to darker paths. One example is agile velocity becoming the most dangerous software engineering metric when used wrong. However, don’t let that shake your faith in engineering metrics.
There are valuable ones you can use to ensure fast delivery and healthy team culture. If these metrics resonate with you, you’ll probably be interested in looking at LinearB, a tool that correlates Git and Jira statistics, offering you unique insights on your team. Click here to schedule a demo.
