Who is this article is for?

This article is written for those with management and budgetary responsibilities for a software development project or team. Others, including developers, quality assurance personnel, and CEOs/CIOs may find interest.

Why would we need to estimate story point cost?

Story points are used to estimate work. Investment in that work is expected to derive some benefit. If that benefit is expected to be financial then understanding the cost of that work is essential to deriving any meaningful ROI. Even if no ROI is expected and the intended benefit is regulatory compliance ( as an example ) then company leadership usually wants to understand what how much of their limited financial resources is going towards any specific feature, iteration, or release.

How do we do it?

The technique presented here is a historical parametric approach. It relies on past data from previous projects. So, one has to have some of this data saved up before a reliable figure can be derived.

RC = Total dollar cost for a historical releases in a product

RSP = Total story points that contributed to that release.

RSPC = Release Story Point Cost

RSPC = RC/RSP

Once you have this for one release you should calculate it for all historical releases. The next calculation is an average:

Average RSPC per product = ∑ RSPC¹, RSPC²……..RSPCⁿ / N

If you want the story point cost across all products then average it again. Although, for most planning purposes it’s useful to plan by product line and this higher level of abstraction of cost might be too watered down.

What questions does this help answer?

1. How much will it cost to add this feature?
2. How much will it cost to deliver release 2.1.0 ?
3. What is the cost of an average iteration?

How often should it be updated?

The astute among you will notice that we’re using historical data. Historical data is only accurate as long as change doesn’t take place. To counteract the shift and change in time size, capability, and mix one needs to do these calculations at regular intervals. How often? This is a judgement call. I do it monthly as I’m in rapidly growing team with many new products popping up. I constantly need to reassess my cost driver.

A more stable team and product might require only 6 month intervals. The relevant point here is; keep it accurate.

Summary

Story point cost ties a rather abstract and developer centered concept to the real world of business. This is necessary. If we intend to use story points in a meaningful fashion in our development environments than they must have some corollary to the spreadsheets, and ledgers that the world’s businesses run on.