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?

Improve this question
4
  • 6
    3 down-votes with no close votes asking a fundamental question that every project manager has about agile development? I don't think this that bad of a question.
    – Greg Burghardt
    Jan 9, 2020 at 19:39
  • This is not a SE question, this is a business question. You are going about it the wrong way, though; the business cares how much it's going to cost them in total, not what's it going to cost you - you'll charge more than that because you need to make profit. Fixed price, fixed scope, fixed time is a death march; you can't have it all, so in agile, you negotiate an arrangement where some of these can be flexible - most importantly, it's scope that varies (e.g. renegotiate for each sprint, allow project termination for a % of total price, etc.) 1/3
    – Filip Milovanović
    Jan 10, 2020 at 14:06
  • In that context, techniques like story points allow you, first and foremost, to have some idea how much work you can actually do within a sprint, and negotiate what goes into it ("if you want that done, we have to remove this"); presumably, you have already agreed by that time how much things are going to cost them; you are just controlling the scope and pacing now. Do the most valuable things first. 2/3
    – Filip Milovanović
    Jan 10, 2020 at 14:06
  • P.S. The whole point of "points" is that they are an abstraction; they don't have a real value up front. Initially, you don't understand the problem domain and the challenges enough to give a reliable estimate, so you assign points as a reference value, and then over several iterations, when you can see what it actually took to implement that stuff, you make new estimates relative to the reference values, refining along the way, so that your estimates become more realistic - letting you plan/negotiate sprints. 3/3
    – Filip Milovanović
    Jan 10, 2020 at 14:06

3 Answers 3

Reset to default
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.

Improve this answer
6
  • +1 The person hours to complete 1 story point is fluid. It changes over time. An 8-point story today might be split up into two 5 point stories next sprint, but takes roughly the same amount of time. Changes in team members also change story points. A team of seasoned developers say this is an 8 point story. They find other jobs and you hire some that are much less experienced and more of them. They view story points differently, and now one 8-point story becomes three 5-8 point stories.
    – Greg Burghardt
    Jan 9, 2020 at 19:42
  • Because of the fluid nature of story points people recommend re-estimating your backlog periodically. That's another sign you cannot convert story points to cost.
    – Greg Burghardt
    Jan 9, 2020 at 19:45
  • Thanks for your answer. Given your perspective, if you had to budget money for the year for a given project, how would you make sure you have enough to succeed? Based on what you say I can only determine how much it will cost me to keep the team working for a period of time, but not how much they actually deliver in that period. What if the team is working on multiple products/projects at the same time. It is still very confusing how could the business budget the cost of individual efforts upfront? It seems that's the gap in my knowledge.
    – edalorzo
    Jan 9, 2020 at 20:02
  • @edalorzo: estimating work is a whole different subject (and question).
    – Greg Burghardt
    Jan 9, 2020 at 23:14
  • @edalorzo You don't know how much they will deliver in that period. But it doesn't matter that much. You wouldn't fund the whole year at once anyway. Maybe you'd spend a little bit of time organizing the first batch of work and then 1-3 months building and see where you got and then revisit. Maybe you'd learn that you don't need any more and your goals are accomplished. Or you know more and you want to build a little more. Or that your whole ideas were flawed and you just saved 9 months of development. Regardless - you fund iteratively and incrementally.
    – Thomas Owens ♦
    Jan 9, 2020 at 23:20
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.

Improve this answer
6
  • It's only useless if you treat it as an iron-clad guarantee.
    – Robert Harvey
    Jan 17, 2020 at 17:49
  • @RobertHarvey I would be willing to bet if you put that number out there, somebody will treat it as a guarantee even if you don't intend it to be taken that way.
    – Bryan Oakley
    Jan 17, 2020 at 18:21
  • Not really my problem. The same could be said of any estimate.
    – Robert Harvey
    Jan 17, 2020 at 18:22
  • @RobertHarvey: The point is that "this is an estimate" is often lost in translation, especially when giving a number, which implies precision. e.g. if I tell you I am 27 years old, would you assume that I was rounding? Maybe if I'd said 30, but 27? It's much more reasonable to assume that I know the exact count. If you pass this information along to a third party, they too will think that this is a precise measurement. You can say it's not your problem, but if the shit hits the fan and some of it lands on you, it will be your problem regardless of how much you argue that it shouldn't be.
    – Flater
    Jan 18, 2020 at 23:40
  • @RobertHarvey A really stellar example here is in the Chernobyl series (link to relevant scenes), where the initial reading of "3.6 röntgen but that's as high the meter goes" becomes "i'm told it's 3.6 röntgen" and then "it's precisely 3.6 röntgen" when communicated up the ladder.
    – Flater
    Jan 18, 2020 at 23:47
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.

Improve this answer
3
  • In this case, why are there burndown charts? Do these not plot story points based on time? I feel this is just backward thinking, eventually you always end up back at hours per story because of burndown charts and the like.
    – Gertjan Brouwer
    Jan 9, 2020 at 19:05
  • @GertjanBrouwer: Burndown charts exist to see if you are currently on track to meet your sprint goals. It's all about the current sprint under way. Extrapolating other information from burndown is pretty difficult and error prone.
    – Greg Burghardt
    Jan 9, 2020 at 19:46
  • @GregBurghardt total amount taken in sprint / total amount of story points in sprint = time taken per story point. This is almost always used by management to determine time taken for a project
    – Gertjan Brouwer
    Jan 9, 2020 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.