Agile Finance: Story Point Cost

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, product management 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 return on investment ( ROI ). Even if no ROI is expected and the intended benefit is regulatory compliance ( as an example ) then company leadership usually wants to understand how much of their limited financial resources are being spent on 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.

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?

How much will it cost to add feature X, Y or Z?

How much will it cost to deliver release 2.1.0 ?

What is the cost of an average iteration?

Can we complete all our story points within our remaining budget?

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 through time of team size, team capability, and complexity of work one needs to do these calculations at regular intervals. How often? This is a judgement call. I do it monthly as I’m in a 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.

Example

Now let’s get a better idea of how this plays out with a recent example on a program I’m leading right now. The program is called Patient Kiosk. The purpose is to build an integrated hardware/software platform that patients can use to educate and participate in their healthcare via a bedside, arm mounted kiosk. As you can guess there are many efforts around this program, not all of them software related, but the ones that are use agile techniques and story points for estimation.

We use Jira for tracking stories and story points, but the creators of Jira have seemingly focused their product strictly on developers. There is no real financial and budgetary mechanism for deriving cost of story points. So, I keep track of story point cost using, yes, excel.

I first create a worksheet for each month to track:

Story Points per release

Total Expenses per release

Actual Hours per release

From these 3 data points I can generate the costs and averages I need per month. Figure 1 below shows an example.

Figure 1

My next step is to sum up and average the monthly costing figure to track its change over time. I also created some basic graphs to show trends. You can do a lot here, but it depends on your needs. Figure 2, and 3 below shows an example of this. When product management wants to know how much it costs to build some set of features I just multiple the one of the figures in red by the number of story points the team has estimated.

Figure 2

Story Point Cost - Patient Kiosk

Hours per Story Point – Patient Kiosk

Blended Rates

Average ( per hour ) $ 45.39

Median ( per hour ) $ 46.25

Figure 3

You might ask: “Why are you tracking hours if story points are your cost driver and tool for estimation?” While the software team and I are comfortable talking about story points and velocity; the rest of the organization isn’t. Translating what the team’s velocity means in terms of hours is important to give context to other stakeholders that deal in more traditional forms of estimation.

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.

Good article. It's indeed often needed to translate 'Agile language' into business language (spreadsheets).

The article only covered the cost side. The same analysis should be done when trying to estimate the ROI of new features. You need to get input from your Sales&Mktg to evaluate the increase in sales if they had a certain feature in the product.

This approach lets you calculate the expected ROI on each feature. Obviously there are other things you should take into consideration (how strategic, ...).

I have avoided doing this for one very basic reason. Story points are only relative to each other within the collection of user stories at a single estimating session. A 5 point story estimated by one team may require much more or much less effort than a 5 point story estimated by another team on another. Comparing and averaging is therefore meaningless, unless you have a very large set of projects to make it all average out.