Swishing the Three Pointers: How Story Points Allow Agile Teams to Nail Work Estimates, Every Time

Swishing the Three Pointers: How Story Points Allow Agile Teams to Nail Work Estimates, Every Time

Do you ever have those days where you don’t even check one task off the to-do list, because the first item ends up being so (dang) complicated?
For most of us, it happens all the time. Take a car repair, a visit to the doctor’s office, or the first day using a new software. These sorts of things are notorious for taking way longer than they “should” or than we anticipate, then throwing off the rest of our plans.

Anytime a task or work item involves uncertainty or complications, it’s difficult to come up with a hard and fast estimate of how long it should take to complete. And with the agile methodology, story points provide a solution for navigating this messiness. They provide an approach to develop accurate estimates around work packages.

Because just like everyday life, some projects look like such a tangled mess that no one can decipher how long they will take to complete. But a company stands to lose a lot of capital when estimates are off. If a ten week project bleeds into fifteen, it’s money down the drain. So rather than sweat blood over this uncertainty, agile teams have come up with a method that solves it.

If you’re wondering what the story is with story points in agile, and the secret sauce that goes into estimating them, then this post is for you. We’re going to explain how story points benefit a team, how to go about calculating them, and more!

What Are Story Points?

Let’s start with a common conundrum that software teams often face. Say a team has two projects it’s slated to complete. The first project is fairly complex, but the team has already completed dozens of similar projects in the past. The second project is simple and straightforward, but requires using new software and engaging with a new client.

The characteristics of each of these projects may well affect how long they take to complete. While the first project is known, it’s also complicated. The second seems simple, but it involves a lot of uncertainty.

Placing hourly estimates around each of these projects is a complete shot in the dark. How can a team precisely pin down the hours it’d take to complete work that’s fundamentally uncertain and complicated? If they tried, the estimates may well end up being several weeks off. And then how does it go about budgeting and billing clients?

Instead, the team resorts to using story points to assign estimates around projects. And these point assignments capture several components of work that an hourly estimate leaves out.

Definition of Story Points

Story points are a unit of measure assigned to individual tasks and larger projects. They evaluate several facets of a piece of work and then assign it a point value. The criteria it uses to estimate work are: the amount of work required, its complexity, the risk and uncertainty, and the team’s definition of done.

Amount of Work 

The most basic component to a story point estimate is the amount of work required. An assignment to bake two pies would have a higher point value than an assignment to bake only one.

The estimate factors in economies of scale. If all the work is identical and there’s simply more of it, then the additional work tends to be completed faster. For example, baking one pie might receive 5 story points, while baking ten might receive 40.

Risk and Uncertainty 

Secondly, story points consider the risk and uncertainty in a project or task. Maybe a job requires using old equipment that is rusty and needs repair, or working with a client who is ambiguous and demands a lot of back and forth with the team.

When uncertainty is baked into an assignment, the effort required to complete it usually is similarly unclear, and so its story point assignment is higher.

Complexity 

Thirdly, story points consider the complexity of a task or project. Take for example repair items on a car. One is to change the oil, and the other is to overhaul the engine. The second task involves far more processes, equipment and skill than the first, and this complexity is reflected in the story point estimate.

Definition of Done: 

Finally, a story point estimate considers all of the work required to bring a task completely over the finish line. Take writing code, for example. A story point estimate cannot simply consider the effort it takes to write the code. Because at that point, it still needs to be integrated, tested and then documented.

Teams come up with their own definition of done around a specific task, and considers all of the hoops it must jump through when assigning a story point estimation.

These are four criteria that factor into assigning story point values to work. If one work package receives an estimate of 2 and another 5, it means that the latter entails more complexity, uncertainty or work to complete. However, it may not necessarily take more time to complete, as story points do not correlate directly with time.

Story Points Are Relative, Not Absolute, Values

One significant characteristic of story points is that they aren’t a standard unit of measure, such as a minute or a pound. Rather, story points are relative values, and are assigned based on how one work package relates to others within the same project. A work item that is five story points doesn’t have any significance unless it’s compared with other work packages within a project.

This quickly summarizes the essence of story points. A more complete understanding of how they function requires looking at them within the context of the agile method as a whole. Let’s go there next.

How Story Points Work in the Agile Framework

Story points are one component of the agile system. In order to better understand how they work, let’s first look at an overview of agile, and then at a few components of the agile system.

Agile is a specific approach to tackling work. Fundamentally, this approach fosters autonomous teams, approaches work in small batches and embraces uncertainty.

Agile Teams Are Autonomous

The agile method believes that the best way to deliver quality work is to hand over the reins to those persons completing the work. And so agile teams receive little guidance or interference from an executive or project manager. The development team owns its own processes and works together to develop its own methods and systems. The entire agile system in fact is more of a framework than a methodology, as it aims to give teams the leeway to identify systems and approaches that work for them.

Agile Is Incremental

The agile approach is iterative; it completes work in short bursts, then takes time to evaluate its progress. Agile teams use story points to determine how much work to take on during each increment.

Agile Embraces Uncertainty

And most fundamentally with respect to the topic at hand (story points), agile embraces uncertainty. This method is most suited to a project where the outcome and the processes are unclear (when a project is fairly straightforward, the waterfall approach might be superior). As such, its approach to work is somewhat non-intuitive. Rather than plotting things out all at the beginning, it executes on a project before it has a lot of the answers. It steps into the unknown, without laying many fixed parameters beforehand.

But this uncertainty demands a method to wrangle it. Rather than write snafus off to happenstance, agile digs into batches of work to find an explanation for why things go awry. This enables it to garner accurate estimates around work.

With this simple overview of the agile theory, let’s now go over three components of agile: user stories, the backlog, and sprints, to demonstrate where story points fit into the mix.

1. User Stories

The term “story points” has its origin in “user stories.”

User stories are the “skeleton” of a project, or a collection of all the tasks necessary to bring it over the finish line. They’re composed by all the project’s stakeholders and completed during the project’s planning stage.

User stories, as the name suggests, are written from the perspective of the end user. “I want this app to notify me whenever I receive an incoming email,” is an example of a user story.

As user stories essentially become the “to-do list” for a project, they need to be written in such a way that the tasks are coherent. Many teams take the “INVEST” approach to fulfill this criterion. “INVEST” is an acronym that stands for: independent, negotiable, valuable, estimable, small, and testable.

• Independent: A good user story can be completed on its own; it has no hard dependencies with other tasks.
• Negotiable: The task isn’t rigid or narrowly defined but rather has room for play.
• Valuable: The work is valuable to the end user.
• Estimable: The risks, the uncertainty, the amount of work required and the definition of done is clear.
• Small: Ideally, a user story involves a small amount of work. (This also makes it easier to estimate.)
• Testable: It’s easy to tell if the user story has been completed.

2. Backlog 

When they’ve all written according to the INVEST criteria, the user stories are placed into a backlog. Although at first this backlog looks like an incoherent jumble of work, it is groomed to order the work according to importance and logical sequence. (When using the Scrum system, the backlog is groomed by the product owner.)

Many of the stories are decomposed while in the backlog. This means that a large requirement is broken down into smaller individual tasks that can be completed during a sprint, which introduces the next topic!.

3. Sprints

As mentioned, teams complete the user stories in separate bursts of work; these bursts are known as sprints. On its own, the team determines the work it can take on during a sprint.

It uses story points to evaluate the upcoming work and determine which items to take on.

The team assigns each user story in the backlog a point value, and also knows how many story points it can complete during a sprint. The work is selected in conjunction with backlog grooming; the team not only estimates how much work it can take on, but identifies those tasks that are the most critical at its current juncture.

Velocity refers to the number of points a team completes during a sprint. When a team has worked together for some time, it develops a rhythm and intuition on assigning story points and maintaining a constant velocity.
Just like story points, velocity is relative. While one team may complete 50 story points each sprint and another 30, this doesn’t necessarily mean that one is outperforming the other.

To recap, story points serve as a gauge for measuring work amidst the risk and uncertainty that’s inherent to any agile project. The agile team independently assigns these points, and over time develops an understanding of how many points it can accomplish within an iteration or sprint. A team’s intuition around complexity and uncertainty increase with time, and so its story points estimations do as well.

Now let’s get into precisely how the team goes about calculating story points values.

How to Estimate Story Points

Story points are a system for measuring work that accounts for the work’s uncertainty, its complexity, and its quantity. Story points are relative and are measured against a baseline or benchmark.

In order to capture these elements of complexity and uncertainty, story points are estimated using the Fibonacci number sequence. Oftentimes, the story point values are assigned using a method called planning poker.

Fibonacci Numbers

This Fibonacci sequence helps to capture the complexity or risk involved in a work package or project.

Fibonacci numbers are a rapidly increasing number sequence that reflect a pattern that frequently occurs in nature, such as in snail shells, pinecones and hurricanes. The values in the sequence are determined by adding the two previous numbers; 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.

Rather than use values that increase numerically for assigning story points, the rapidly increasing component of the Fibonacci sequence effectively measures complexity and risk. A task with many unknowns receives a high value, of say 55, whereas a task with little uncertainty or unknowns receives a much lower value, of either 5 or 3. (Again, the amount of work is also always factored in, and determines the final story point value).

Planning Poker

Planning poker is one popular method agile teams use to assign story point values (which are Fibonacci numbers) to items of work in the backlog.
In this activity, team members individually assign story point values to tasks, and then the team coalesces to settle on a final estimate for a task.

In order to arrive at accurate estimates, the story points must reflect the collective perspective of all team members. “Anchor bias” might skew these estimates. For example, if one piece of work is presented and one member says “this looks easy,” the other members are more likely to assign it a lower point value. However, each individual member brings a particular perspective and skill set to a task, and so what is easy for one member may not be easy for another. And so the individual estimates are provided without input from other members.

Briefly, here is a summary of the steps to planning poker:

The Equipment:

A deck of cards with numbers from the Fibonacci sequence.

The Players:

The participants in planning poker are those persons who are actually doing the work. So in a software project, this would be the development team.

The Rules of Play:

1. Each player receives a stack of cards with the Fibonacci numbers.
2. The team establishes a “baseline” story value using a simple user story. (As story points are relative, this step serves to provide a benchmark to compare other work against.)
3. The facilitator presents high-priority work from the product backlog.
4. With each item of work, the team members place their story point estimates face down, without consulting with other members.
5. The members turn over their cards at the same time and compare estimates.
6. In the instances of disparities, the team members take turns sharing their rationale behind their story point estimate, outlining the uncertainty and complexity they see in the task.
7. The team continues the voting process, in the same manner above, up to three more times until it arrives at a consensus around the story point value to assign the work item.

And this summarizes how teams calculate story points. As requirements evolve, the estimates evolve as well. Planning poker becomes fairly fluid with teams who have worked together for some time. The baseline gauge is understood and so all of the relative values are accurate.

This all may seem fairly complex to anyone new to story points, and one common question is, “Why not just assign hours?” This question deserves some attention, so let’s focus on that next.

Why Story Points, Not Hours?

Story points are a fairly complex idea to wrap one’s head around, and so why not estimate using hours, the method generally employed for estimating work? Wouldn’t it be easier if teams simply looked at work packages, assigned each an hourly estimate, and then selected enough work for each sprint to fill a 40-hour work week?

Theoretically, the business benefit of using hours over story points is abundantly clear. It’s far easier to bill for a job that’s going to take 100 hours to complete than for one that requires 100 story points.

However, agile teams have found that this logic only applies in theory, not in practice. For several reasons, they find that story points are really the superior method.

Absolute Estimates Are Difficult for Us

The principal reason teams utilize story points over hours is that they’ve found that story point estimates are far more accurate than hourly estimates.
Humans, as it turns out, don’t excel at absolute estimating. But we’re fairly proficient when it comes to relative sizing.

With respect to work packages, it’s easy to look at several alongside each other (with a benchmark) and size each up relatively, rather than look at each item individually and estimate how many hours it’d take to complete.

Story Points Account for Uncertainty

Story points gauge for uncertainty, which is fundamental to any agile project. In the same way that a trip to the grocery store takes 25 minutes on a Monday but 50 minutes on a Saturday afternoon, the same amount of work takes longer depending on who is doing it, when it’s being done, and how external factors impact the work.

A work package with high risk and uncertainty may be assigned a Fibonacci value of 21 or 33. This forces it to be decomposed into smaller work packages that are easier to scrutinize and estimate. Hourly estimates, however, increase numerically, and so don’t readily capture uncertainty.

Story Points Account for Risk

Again, hourly estimates that increase numerically don’t readily capture risk. Hourly estimates might cram high-risk work into a fixed time slot, forcing it to be completed sloppily and with many defects.

The rapidly increasing Fibonacci numbers, on the other hand, cushions for this risk by assigning a high value to high-risk work packages.

In many respects, then, story points work much better than time for estimating work in agile.

How to Estimate Cost With Story Points

In the real world, where money is measured in time, story points are meaningless. Yet in order to create competitive quality products, a team must utilize story points. This conundrum may well have the business owner pulling his hair out. How does a business address it?

An experienced agile team offers a simple solution. Story points needn’t be a total departure from the real world of time and money. Teams have discovered that although they cannot directly correlate individual story points to a given number of hours, they can over the space of a week or two (a sprint) come up with a reliable estimate of how many points it can complete. In a strong agile team, this velocity remains constant from sprint to sprint.

This consistent velocity then, provides a reliable gauge for evaluating a project with respect to time. It allows a team to assign a story point value to an entire project, then accurately estimate how long it takes to complete.

Say a team is assigned a project to design a website. After user stories have been written and assigned estimates, the team determines a story point value of 144 for the entire project. Assuming the team has a velocity of about 30 points per sprint, then the time to complete the project is simply 30 into 144, or about five sprints.

Although this is a viable solution, it hinges on two assumptions: that the initial story points estimates are accurate and that the team has a consistent velocity. If either of these assumptions prove false, then the time estimate is way off. Here are a two ways to mitigate against this risk:

1. Keep Agile Teams Together

Story points are relative. From team to team, the benchmarks vary and velocities are different.

A team that’s experienced, however, works at a consistent velocity. This known velocity, as well as data gathered from historical projects, makes it possible to gauge the team’s production capacity.

For example, if a team costs $20,000 a week and it can complete work at a velocity of 30 story points, then a project that’s 144 story points (an estimate supported by similar projects in the past) will take five weeks and cost roughly $100,000.

2. Decompose High Level Requirements

As a rule, story points with low values are much more reliable than those with high values. Similar to a work breakdown structure, accurate estimates entails breaking down high level requirements into smaller, simpler work packages.
Although it takes some finagling and translating, it is possible to incorporate story points into a “real world” system where time is money.