Designing and Developing Cross-Cutting Features
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
Article
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Agile Finance: Story Point Cost
Posted by Christopher Goldsbury on Aug 18, 2010
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.
RelatedVendorContent
How ALM Drives Business/IT Alignment, Competitive Advantage
Related Sponsor
Learn how Application Lifecycle Management can support your business processes in this exclusive presentation by David Chappell.
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.
- This article is part of a featured topic series on Agile and also Business/IT Alignment
- See more Agile content at: http://www.infoq.com/agile
- See more Business/IT Alignment content at: http://www.infoq.com/business_it_alignment
- Other recent content items in this topic
Agile ROI analysis
by
Fabrice Talbot
Posted
Story points not relative across projects
by
Chris Davies
Posted
Re: Story points not relative across projects
by
Nicolaas Kotze
Posted
Re: Story points not relative across projects
by
ankit vaid
Posted
Do you assume a static team?
by
Ahmed Mahdy
Posted
-
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.
-
True. As a tester I really struggle with this story point concept since testing never finishes but only stops and that in general "developers don't do testing".
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. -
Thanks this is really helpful resource - Ankit Vaid
-
What if I have 5 teams and we change team members , how can I get a reliable avg cost of story point ?
5 comments
Watch Thread Reply