Story points vs. invested money

Why does management want this information? Isn't the Product Owner accountable for the value the team delivers? He or she ought to be in a position to answer whatever questions stakeholders such as management may have. That would make far more sense than trying to commoditize story points, the only purpose of which is to help teams estimate how much work they can take on.

Hi Ian,

Thanks for your reply. 

I don´t know why the management wants to know theses costs. My assumtion is that they need it in order to invoice this costs. Currently I am looking for someone who can answer me this question. 



Of course, the Product Owner is accountable and should be able to answer these typ of question. I´d like to help him somehow. And I would like to avoid the misuse of story points.

Is this a misuse of story points? Yes, it is.

Is this a way to, with statistical level of detail, estimate money investment is something? Yes, it is.

Even if doing it for one feature can be skewed due to factors you mentioned, if done many times will give some results.

Personally, I would emphasize that this is a gross misuse of story points and ask why it is not allowed to track hours that are worked because hours worked would be a better value to use instead of story points.

Think about it like this, I can run "really far" in a "pretty decent" time so I want to track how fast I can run a mile to see how I would place in an upcoming race. The problem, I don't track my run in miles; instead I use the blocks in my neighborhood. 1 day I run 10 blocks in 25 minutes and the next day I run 8 blocks in 30 minutes, the following day I run 15 blocks in 35 minutes. How do you calculate how much time it takes me to run a mile? It's impossible. The size of the blocks are not the same, some blocks have steep inclines that take longer to run, others have a winding/snakelike sidewalk that takes more time to run.  

Get my drift? It doesn't make sense because the "value" of story points fluctuate with each sprint and product. Over time the story points will typically become a bit more stable but it is still not something that could accurately be used to calculate the value of a story point.

Ideally, story points should not be used as a measurement for anything outside the team. Your situation is not uncommon (I've experienced it myself), and in the past I've attempted experiments to measure cost against estimated size. It can work to an extent, but generally falls over when the team do not have consistent stability - occasionally teams may not complete stories for whatever reason, and figuring out how a sprint is 'financed' at that level becomes very difficult using this method. This can also potentially put undue pressure on the team to deliver a certain number of points per sprint, which is not the real intention of using them.

In theory, a typical team should have one focussed goal in a given sprint - if they only concentrate on delivering one feature (goal) together, and you know how much it cost to finance that sprint, then your cost tracking of that goal is straightforward. Multiple features/products with a team's sprint can very quickly become complicated to track, and above all, if one team is working on several initiatives in the same sprint, are they really one team anyway? Can the team be broken down into smaller, separate teams to each deliver an independent piece of shippable functionality?

The simpler/smaller the team and the work is, the easier it is to track the costs.

Hi All,

This seems to be an old thread, however, I would like to add my feedback and honest difficulty in assessing cost of development of a feature and why it is really important from a management perspective.

I work for a Product company, and ever so often we release features or develop platforms that result in significant economic returns. Given this, we do not expense the development cost, rather we capitalise it - There's a great article by Dan Greening, in which he elaborates the importance of capitalization :

https://www.infoq.com/articles/agile-capitalization

To capitalise cost of development, some companies literally sit down with PMs frequently and get a rough time allocation each teammate spend developing some part of the feature that qualifies for capitalisation. Clearly, this is mostly inaccurate, and not well documented for auditors.

More challenges arise when squads are not dedicated to the development of this feature/product.

If time-sheets are a no-go, businesses still need a good, and documented approach to calculate budgeted as well as actual cost of development. This is why management looks scrutinizes agile metrics and attempts to convert it to cost.

I'm thinking the above query (Story points vs. invested money) is mainly chased by organizations serving multiple (internal or extrenal) clients (and, in doing so, using the a "pool" of talent). If so, then "hours worked vs. invested money" seems more appropriate, though it's far from being the most accurate description (or approach).

Conversely, if development is done through dedicated teams, then salaries / rates should provide a pretty decent picture of how much it "costs" to develop. The business would, of course, want to use that cost against its most important initiatives - features - stories - you name it.