The main idea behind using story points is to take away focus on the absolute time/cost of a task and look at the relative sizing vs the other tasks you have in front of you.

This has worked well in all the other companies I have worked in. Here the typical setup is that you have a software team, working on a product, and a product owner which can use the story point estimations to prioritize one feature over another for the next sprint and/or release.

However, in my current position it's a bit different. We develop software for a hardware platform we sell to customers. However, all sales requires us to tweak our software to match the customers' needs[1], and this tweaking is often a significant cost for the company when selling a product.

Therefore sales/management always needs an estimate of how time-consuming various customer-related tasks are, so they can factor this number into their offers when they bid on jobs.

We spend roughly 50% of our time integrating our base software into customer specific solutions, and 50% of the time on improving our base system.

Question: In this case. Does it even make sense to try to abstract away time/money from the development using story points, since numbers are always so close anyway?

When sales comes and asks: "[The customer is willing to pay $1 million extra for feature X,] how expensive is feature X to develop?" It's impossible to not look at the number $1 million then the amount of story points for the task, and make a direct transformation.

You could argue that you should not tell the developers about the actual number, but I don't like this for two reasons:

  • I don't know what you actually gain from it here. You still need a direct story point->time->cost transformation
  • We are only around 20 people in total, 8 in software. A sale is a huge thing, and I think taking away information of how everything is going would stress people more than giving them peace of mind to "just work on development".

[1] Either to make it integrate into their current system(s) or give them an edge in their market.

  • 1
    You're asking the wrong question. If your time-based estimates are accurate enough for your purposes, then that's great! If they aren't accurate or effective, then continuing to estimate in units of time isn't serving a useful purpose. Only you can determine how accurate your current estimates are.
    – Todd A. Jacobs
    May 28, 2018 at 15:50
  • Not a fully fledged answer but I have seen a CISO function do something similar with their cost centre. They worked out their total delivery for the year in story points by extrapolating the previous year. So in 2017 they delivered in 26 Sprints 540 points of work. They got a budget in 2018 for the year and simply divided that budget by the 540 points. So $2mill divided by 540 = $3700 per point. Then when other business units would ask how much it would cost for a security feature..they would estimate the work. 3 points = $11100. This requires really good empirical data from the past Jun 8, 2018 at 18:51

2 Answers 2


In Scrum you have a very useful cost measurement point: the sprint.

Given that you have a dedicated team and time-boxed sprints then estimating the cost per sprint is relatively simple.

So there is nothing to stop you from using story points to estimate your sprint capacity and using sprints to estimate your costs.

However, as you are following the agile approach then the usual caveats must apply:

  • If responding to feedback is important to you, then it is likely that scope will change over time
  • If you are adapting to change, cost estimates will also be subject to change
  • The further ahead you estimate, the less likely it is to be accurate
  • I understand what you are saying. However, in our workflow we typically divide up the tasks so some people are working on R&D while other people are working on customer releases. Of course you can see how big a part of the spring is used for customers, but again it feels like you are just converting storypoints to dollars
    – Markus
    May 28, 2018 at 10:57
  • I've been in a similar situation working for a consultancy. If you have to track time at the hour level, then so be it. But if at all possible, try and track it at the sprint level. Perhaps by having a short sprint length and dedicating it to either R&D or a customer release. May 28, 2018 at 12:09

The advantage of using story points is that they free the mind from the pressures of schedules and external expectations. By only having to weigh tasks against each other you generally achieve more reliable estimates.

That does not mean you can't offer your sales team a translated version. You can and you should. You can use your team's velocity history to project how long an set of task is likely going to take.

It's important to note that such a calculation needs two things to be accurate:

  • consistent velocity
  • low level estimates

If you don't have consistent velocity you can still use your known range of velocities to give a range of estimates which is better than no estimate or one pulled from thin air.

And if you need these time based estimates before you have reliable low level story point estimates the same empirical principles can be applied. Make sure you save your original estimates and when you complete a project sum up all the refined estimates. Over time this will give you an idea how your refinement is affecting your story point count. You can then use the histories of velocities an refinement conversions to calculate a likely range of translation values.

You can do a simple (average velocity) * (average sp conversion) * (high level sp estimate) = (estimated time) or you could go and run a monte carlo simulation on the whole histories to get confidence intervals and everything.

Still, this is all getting more and more complicated. So as Todd commented on your question, you should go with the simplest solution that works for you. Every layer you add on top is going to cost you time to gather and maintain it. Don't do it if it doesn't add appropriate value...

Your Answer

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

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