When managing a project of known scope, understanding the time required to complete the project (or a piece of the project) with available resources is critical to the ability to plan effectively and appropriately set expectations with stakeholders.

Naturally, workers of differing skill levels will complete a given task at different rates—i.e. a highly skilled worker will work more quickly than a low skilled worker. This fundamental truth of labor can present a significant challenge when estimating timelines in man-hours, as estimates produced by one worker may not hold true for another.

Story points may be used as an alternative to man-hours when planning projects, but before we start using story points, we must understand what story points are and why they are useful.

What is a story point?

At the most basic level, a story point is a unit of measurement. Story points measure the effort¹ required to complete a piece of work.

More accurately story points are an estimate of effort, as story points consider the fact that attempting to predict the future has inherent uncertainties. Story points do not attempt to be precise at a micro level (i.e. tasks), but allow more accurate predictions to be made at a macro level (i.e. projects).

Note: The term “estimate” is used in this article to refer to level-of-effort estimates used in project planning, these types of estimates are not intended to be used directly in a sales context and do not estimate monetary cost.

Note: For the remainder of this article I will use “points” and “story points” interchangeably.

What are story points used for?

Story points are typically used in Agile project management to make predictions about the amount of time required to complete a project with known resources (i.e. a given set of workers of known skill levels).

Story points are about time. There, I’ve said it, and can’t be more clear than that. … The primary reason for estimating product backlog items is so that predictions can be made about how much functionality can be delivered by what date. If we want to estimate what can be delivered by when, we’re talking about time.

– Story Points Are Still About Effort

Making timeline predictions with story points

To predict the remaining time required to complete a project using story points we must have two things:

1. We must know how much work must be done (i.e. the project estimate)
2. We must understand the team’s velocity

“Velocity” is the number of points a team has historically completed over a given amount of time (commonly a one-week or two-week “sprint”).

Note: I like to refer to the number of points an individual has completed over a given amount of time as that individual’s “throughput”. Though “individual velocity” may be a more correct term within Agile, I’ll use “throughput” in this article to differentiate between team velocity and individual velocity.

In the simplest terms, we can predict duration by dividing the total number of points by the team’s historical velocity.

For example, if there are 100 story points remaining within a project, and our team can complete 20 points per week, we can expect that the project will require 5 weeks to complete.

Story Points vs. Man-Hours

At this point, you might be wondering how using story points in this way is different from using man-hours—after all, if we have a project estimated at 100 hours, and our team can devote 20 hours per week to a project, then we can also predict the project will require 5 weeks to complete.

The crux of the issue is that, as we know, workers of differing skill levels will complete a given task at different rates. Estimating in man-hours tightly couples the skill set of an individual worker to the estimate. For this reason, hours-based estimates must be re-estimated when team assignments change (e.g. when team members are added or removed during the project), or when challenges emerge that impede the team’s performance.

Story points decouple estimates from individual workers, providing an abstraction to managers which offers more information about remaining effort. This allows managers to make more informed decisions when allocating resources. Using this method, level-of-effort estimates need not change when the team changes; all that must be done to recalculate the predicted timeline is to update the team’s velocity.

---

Let’s consider an example: Parker, an expert programmer, and Pat, a new employee, are both tasked individually with configuring a web server. The following table shows the actual hours each employee spent on the task.

Task	Parker’s Hours	Pat’s Hours
Configure a web server	4 hours	8 hours

Morgan, their manager, is asked by a new client, “How long will it take to configure a new web server?” … To answer this question accurately, Morgan must understand who is assigned to the task. This underscores the fact that duration is always a function of the resources assigned to a task. If resources change, when using hours-based estimates, the timeline required for completion must also be re-estimated.

Taking this example further—the client makes a request to build a new microsite. We want Parker and Pat to work on the project together, and we understand that this task is roughly 10 times the effort of configuring a web server. How quickly can we deliver this project? … Stumped? This too illustrates the difficulty of using man-hours for estimating completion.

Let’s try using story points to answer this question instead. First, we must have an agreed upon baseline to calibrate our story points. We will use the task of configuring a web server as the baseline, and assign 4 points to this task.

Task	Story Points
Configure a web server	4 points
Build a microsite	40 points

Note: The number of points assigned to the baseline task is not important, so long as we can measure other tasks accurately in relation to that task.

Remembering that duration is always a function of the resources assigned to the task, we must also determine how many story points both Parker and Pat are able to complete within a given time frame (throughput). Based on their previous work configuring the server, we can infer the following:

Team Member	Throughput
Parker	1 point/hour
Pat	0.5 point/hour

Note: The conversion rate between points and hours again is insignificant, so long as it is consistent across the team.

We can use this information to determine the team’s velocity by combining Parker and Pat’s throughput.

We now have all the information we need to answer the question “how long will it take Ted and Pat to build a microsite?”

In this way, managers may more easily and accurately predict timelines. Additionally, managers may reassign resources without having to reestimate individual tasks.

For instance, suppose Morgan needs to reassign Parker at the last minute, and replaces Parker with Jamie, an experienced programmer. Jamie can configure a server in 6 hours, and therefor has a throughput of 0.75 points/hour. Let’s see how this impacts the timeline:

Morgan can now appropriately set stakeholders’ expectations or assign additional resources to the project.

Points to Actual Hours Conversion

Recall that story points are a measure of effort. Story points make the assumption that, over time, the average velocity of the team—the amount of effort they’re able to invest—will be reasonably constant. Assuming point value estimates are consistent across the team, estimates based on points and historical velocity should be fairly accurate and should not fluctuate wildly. Additionally, the longer this process is used, the more accurate it becomes.

Unfortunately, time is not a precise measurement of effort—as we’ve seen, one “one point” task might require 30 minutes to complete while another “one point” task might require two hours to complete, depending upon a number of factors. More accurately, one point equals a range of possible values representing a normal distribution centralized on a mean with some standard deviation. For this reason, story points cannot be directly translated into actual hours. It is possible to determine the mean, though it may not always be accurate.

The most important attribute of a story point is that it is a common unit of measurement across the entire team. A unit of measurement must remain constant to be an effective tool. If point estimates vary between team members then velocity cannot be tracked accurately, nor can velocity be used to make future predictions about expected timeline. Story points are meaningless if the team does not have general consensus on the value of a story point.

Calibrating the Team

Estimating in story points requires commitment from the entire team. Everyone must agree on what “1 story point” represents in terms of effort. Before a team can effectively use story points, the team must be “calibrated” so each member shares a common understanding of the value of a point. Selecting a baseline that is commonly understood will make calibrating the team easier.

When a team is properly calibrated, a points estimate should be able to be validated with any team member, and that team member should arrive at (roughly) the same point value assigned. Planning poker, a variation of the Wideband Delphi method, is one effective method for calibrating a team.

Another approach to calibrate the team is to use the highest or lowest performer to set the baseline. It may be easier for the team to agree “it should only take a high performer X hours to complete this task.” This was demonstrated in the previous example where Parker had a 1-to-1 points-to-hours ratio.

Communicating with Stakeholders

Presenting clients estimates in hours can establish expectations which may be difficult to revise. Because story points abstract hours estimates, clients cannot draw conclusions between story points and hours. However story points do offer the client the ability to compare the relative size of one task with another.

While this approach may effectively move focus away from hours estimates, it does not address the client’s primary concerns—namely, the price of a project, and the delivery date. If work is priced commensurate to the value the customer receives, if timeline is adequately communicated, and if there is trust established based on a history of meeting deadlines, then inputs (man-hours) will be irrelevant to the client.

The opacity of story points makes them an ineffective tool for managing client expectations. Timelines should always be delivered to the client as delivery dates rather than as a number of hours or number of points.

---