After working with story points for a bit, teams often realize they can calculate the team’s cost per point. The team’s product owner can use this cost per point to make decisions. For example, suppose a team’s cost per point is $2,000. Their product owner could then estimate that a 10-point product backlog item will cost about $20,000 and be able to decide if the item is worth that investment.
Shortly after many teams realize such calculations are possible, though, they’ll often ask me if they’re dangerous.
Before considering whether calculating a team’s cost per point is dangerous, let’s first look at how it can be calculated and how it can be used.
Calculating the Cost per Point
To calculate a team’s cost to deliver a story point, start by selecting an appropriate time frame over which to do the calculation. I recommend using at least three sprints’ worth of data. I’d actually prefer three months of data, which will likely be more sprints, depending of course on sprint length.
For the period you’ve selected, calculate the total number of story points delivered. To do that, simply sum the velocities for each sprint. Let’s use the data in the following velocity chart. During the seven sprints shown (14 weeks), this team delivered 167 story points.
Next, determine how much the team was paid during the same period. The personnel department is unlikely to share individual salaries with you. But they’ll probably give you the sum, and you don’t need individual salaries. All you need is the total paid to the team over the period.
You’ll need to think who you want to include in this calculation. Maybe your team consults with an architect occasionally. Or they work with a DevOps Engineer who isn’t officially on the team but helps out a few times at least each week. It’s up to you whether to include partial salaries for these folks. Usually part-timers won’t materially affect any decisions based on a team’s cost per point.
Additionally, you’ll need to decide between using salary data and fully burdened (also called fully loaded) labor costs. Fully loaded labor costs include an allocation for office space rent, benefits, paid time off, etc. All this means is that a team member who earns $40 per hour costs the company more than that. You can usually get the complete figure from a controller or someone in the finance group.
I recommend not bothering with loaded labor costs because, as with part-time team members, it usually won’t lead to different decisions being made.
An Example
Let’s suppose we have a team of eight people who were paid $160,000 total over the 14 weeks being analyzed.
From the velocity chart above we determined this team delivered 167 story points. To determine the cost per point, divide the total cost ($160,000) by the number of points (167) and get $958 per point.
Using the Cost per Point
There are a number of ways a cost per point can be useful. I’ll describe two. First, the cost per point can be extremely helpful to a product owner who needs to decide whether a feature is worth developing.
Prioritizing a Feature
Imagine you are a product owner whose team has just estimated a feature to be 40 points. Knowing your cost per point is $958, the question in your mind then becomes whether the new feature is worth spending $38,320 ($958 x 40).
Actually, I’d hope you’d just round that off and think about whether the feature is worth $40,000.
Even better would be for a product owner to understand that 40 points was the team’s estimate. A decision about building a new feature should include some margin of safety in the decision. I’d recommend the product owner add at least 50% and consider whether the feature would be worth it at that cost.
Earlier today I bought an old issue of Rolling Stone magazine that I want to frame and hang on my office wall. It was $200. Since I only have the eBay seller’s word and photo to vouch for the quality of the 45-year-old issue, I had to ask myself if I’d still pay $200 if the magazine isn’t quite as pristine as I’m hoping for.
It’s the same with the product owner making prioritization decisions. I don’t want a product owner to have the team build something that is estimated at 40 points that the product owner would not want built at 41 points.
Estimating Development Cost
A related use of a team’s cost per point is to estimate the development cost of a product, project, or set of features.
This arises frequently in contract development. Imagine a company approaches a contract development shop to have a new product built. The team estimates it at 200 points. Knowing their cost is $958 per point, they can do the math (200 points x $958) and determine the product will cost just under $200,000 to develop.
Note that they should not then go bid $200,000 to the client. This was an unloaded labor cost and no allowances have been made for uncertainty, project management, client management, or profit. But the $200,000 can be used as a starting point and these additional items added to it.
The Dangers of Using a Cost per Point
Note that in each of these appropriate uses of a team’s cost per point, the value was used in aggregate. It was used as a team cost rather than the cost of one person doing the work. And it was used as the average cost over a large number of points (40 and 200, in the two examples).
Danger: Using Cost per Point Too Narrowly
This is an appropriate use of cost-per-point data. Things can go wrong if the cost-per-point is applied too narrowly. A mistake I commonly see involves someone looking at the cost per point at an individual level, for the individual velocity of each member, which is a very bad idea.
Individual velocity should be impossible to calculate because a team shouldn’t have backlog items that can be delivered by one person. A typical backlog item might require a programmer, a tester, a DBA, an analyst, a user interface designer, and more. With so many disciplines involved it would be impossible to allocate points to each role. So velocity can be calculated only at the team level.
Using cost per point too narrowly can occur when looking at small product backlog items, too. Think about a two-point product backlog item and suppose, for simplicity, those two points are split evenly between coding and testing.
The team has only one tester but has two coders, each equally likely to pick up the item. One programmer earns twice the salary but is actually three times faster at coding. On one small product backlog item, the cost per point could be affected by which team members do the work.
But if this same team is using their cost per point to make decisions about 100 points of work, it would be impractical to think all that work could be done by one particular developer. No—with the larger amount of work, things will average out.
You want to be careful of using cost per point at too small of a level.
Danger: Using Cost per Point to Compare Teams
The biggest danger in calculating a cost per point is the risk that someone outside the team will use it as the basis for comparison against other agile teams. This is inappropriate because the velocities of two teams are not comparable unless the teams have taken great effort to establish a common baseline for story points and to maintain it. And, even then, it may not be a good idea to have a common baseline.
The desire to compare teams based on cost per point follows from the mistaken thinking that velocity can be used as a productivity measure. It can’t. It is entirely possible for a team with a lower velocity to be more productive than a team with a much higher velocity.
Cost per Point Can Aid Decision Making
I believe that knowing a team’s cost per point can help people choose. The metric is easy to calculate and easy to use in ad hoc situations; working with round numbers and rough estimates is enough to help a product owner decide if a feature warrants the estimated effort.
The primary drawback of it being used to compare teams is not a new foe for most Scrum Masters or coaches. Stakeholders often attempt to compare teams—but they’ll attempt that with velocity alone, so knowing each team’s cost per point doesn’t worsen the situation.
