5

How can I determine the monetary cost of a user story point in a given team?

I was asked this question recently since the business is interested in determining how much a given project could cost them.

Now I know a user story point is a subjective measure of estimation, e.g. The team assigns T-shirt sizes to the stories: small (1 point), medium (2-3 points), large (5 points) and extra-large (8 points), etc. This estimation of the size is very subjective and if the team changes in any way, what they subjectively consider small, medium or large could change as well.

I know that after trying planning poker for a while, the team calibrates their estimation subjectivity and eventually this becomes evident in the fact that the team delivers (on average) the same amount of subjective story points per iteration: our team velocity.

However, the problem is that my team has changed several of its members recently, some of the new members don't know the domain yet and/or have less professional experience. We won't know our velocity for a while.

So, bottom line is that thinking in agile terms, I have no clue how one could determine the cost of a story point, or even following any other strategy how much a given project would cost.

Any ideas on what's the right way to do this using a formula that makes sense from agile perspective?

edalorzo
  • 2,676

3 Answers3

8

You don't convert story points into money. The cost of a software development effort is a function of the team for a period of time, perhaps considering resources if you forward those costs along. However, story points do not convert to time, so you cannot use them as an input into cost. Story points are also highly volatile, so even if you tried to convert story points to time, it would not be a long-lasting function.

There's no good way to determine how long an effort executed consistently with agile software development will last. This is because agile software development is about responding to change - we know that software development has a large number of unknowns and we learn more as work progresses and software is put into the hands of stakeholders. Sometimes, we learn about what is needed and other times we learn what is not needed - in either case, the scope is very dynamic.

The common answer is that you know how long it takes to pay for a team to work for a period of time. Given an ordered (often considering priority and dependencies) set of work, you can estimate how long it would take to do that particular chunk of work. If the stakeholders can quantify how valuable that work is to them and the development organization can quantify the cost of development, then there can be an agreement on if it is worth it to pay for another iteration or two.

Even if you had recent velocity (Yesterday's Weather), it would be difficult to project too far into the future. The things that you learn could add or remove work. As the team learns, they also learn more about how to do the work and what issues there are. But rapid iterations and feedback help to align and identify when the costs outweigh the benefits of proceeding any more.

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
4

Story points at least arguably should never leave the team room -- it's not something higher-ups need to know.

However, if they hold your feet to the fire and insist on a number, and if you've been at it for a while and your team has delivered a product before, just do basic math. Add up all of the story points for the past six or twelve months, and divide it by total revenue minus the cost to pay everyone on the team.

The answer will likely be useless, but so will any other calculation. At least with using real-world numbers, they have a chance of being at least slightly meaningful.

Bryan Oakley
  • 25,479
3

Story points are supposed to be abstract, they are only ever intended to be used as a relative measurement that is quick to estimate. Once you attempt to translate story points into a cost (e.g. 3 points is 15 hours) you get a false sense of accuracy, and your estimates become much harder to come to a consensus on.

If you need to give time / cost estimates, you can, but that should be entirely separate from your point estimates.

Brandorf
  • 149