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.
RC = Total dollar cost for a historical release 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?
- 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.