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. 🙂
Best Answer
You are correct, there is not a formula to convert story points to hours. You can get a pretty lossless conversion of meters to feet, and vice versa, but you can't say a 3 point story will take X hours, so a 5 point story will take Y hours (solve for Y).
HorusKol touched on this next part. Your sprint velocity as a team can help out with the longer term deliverables. Say your team is at 50 points per sprint, and each sprint is 2 weeks. So 50 points per sprint multiplied by 50 weeks in a year (assuming people take 2 weeks off for vacations) then your current team can do a maximum of 2,500 points in 12 months.
So the business comes up to you with 170 points worth of stories and epics. Divide that by the team's historical velocity of 50 points (an average of every sprint so far) and you get 3.4 sprints. Since we are doing an estimate, round that up to 4 sprints: 8 weeks. Two months, basically. I also like to take the last 3-4 sprints and take another estimate. Let's say your team in the last 3 sprints has done 53, 67, and 55 points respectively. That works out to 58-ish points, which at that rate is 2.9 sprints — so basically 3 sprints. Looks like your timeline for those 170 points is looking like 6 to 8 weeks.
Tell the business 2 months. Don't tell them 6-8 weeks, because they will just hear "6 weeks." Don't even tell them 8 weeks, because most months have about 4.5 weeks in them, and when people hear "4 weeks" they instantly think "1 month." Once an estimate hits about 4 weeks, it becomes 1 month. Then just work in months. If you hit a year or more then honestly just don't estimate that work. It's pointless. Too much can change in a year.
I've found this to be a fairly accurate way to convert story points to hours... well time, anyhow.
You'll get a variance in the amount of time it takes individual stories to be completed. Some developers work faster than others. Putting all the story points into a bowl and turning the blender on to work with averages helps alleviate those inconsistencies.
Oh, and don't forget the most important part:
Round up. Always.