I'm sure this is not an uncommon theme. We have two scrum teams that are doing an okay job of estimating user stories using story points (the current team constellations are only about 8 months old, although the team members have several years of scrum experience). But it's hard for the business part of the company to relate to user stories; they want actual time units (or "a formula to convert story points to hours") so that they can make a plan for when things will be ready ("we need to know by when we can tell customers that Feature X will be in production").
I, and my scrum master predecessors, have of course explained that "there is no definite relation between story points and actual time" and that "story points are used to determine how much the team can fit in a sprint", and I'm sure you can guess how satisfied they were with that answer. They still want to know, in calendar time, when we'll get to that 27th user story on the backlog.
In any case, I have been compiling some statistics, and our SP estimates translate into wildly different actual-time-spent results (as measured by our scrum board software, which keeps track of how much time tickets spend in the "working on" column). For 1-SP user stories, there is of course a heavy bias towards very short time spans (with the occasional blow-up), but especially for 2-SP stories, they're all over the place: there is a factor of 20 between the "fastest" and the "slowest" completions. For 3, 5, and 8-SP stories, the spread is also more than a factor of 2.
This indicates that (a) the team needs to be much more consistent in estimating user stories of (what should be) similar complexity, and (b) the team needs to improve their accuracy in time reporting (ie. remembering to move tickets out of "working on" when they're in a meeting, at lunch, or playing foosball).
I have plans to improve both (a) and (b) but I feel that's not enough, that the business expects "more concreteness" than what these initiatives will yield.
What are some good strategies in appeasing the business side, so that they will not interfere too much in how we work (eg. by imposing the use of separate time tracking, which IMHO would be dumb because it would in any case be less accurate than the current "automatic" tracking), while at the same time allow them to obtain some measure of concreteness for when stories will be done?
(Historically, during planning we did break down user stories into work items which were then individually estimated in actual work time, but what I'm talking about here are the user stories on the back log that will not have that level of detail or break-down.)
Update: My manager had a hunch that there was a sort of bell curve distribution of hours-spent-per-story-point, but the data I collated and the graphs he made thoroughly disabused him of that notion. :-)