When working closely with sales, does storypoints still make sense vs time estimations

Question

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.

Answer 1

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

Answer 2

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...