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.
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.
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.
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.
Story Point Cost - Patient Kiosk
Hours per Story Point – Patient Kiosk
Average ( per hour ) $ 45.39
Median ( per hour ) $ 46.25
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.
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.
Agile ROI analysis
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, ...).
Story points not relative across projects
Re: Story points not relative across projects
Having a team that is not capable to estimate the time/effort + complexity and exclude impact analysis from evaluating the story, management can do cost calculations until they are blue in the face.
At the end you'll end up with a problem like this www.youtube.com/watch?v=Sygm9x9sBEo&feature...
Nice article to impress a client though.
Re: Story points not relative across projects
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014