Story points vs time

Time is duration: how long this takes you, calendar-wise. Points are relative effort: how big this is compared to the reference story. They don't convert. The moment you publish a conversion table — points-to-hours, points-to-days, points-to-person-weeks — every estimation conversation collapses back into time, and the relative-effort property is gone.

The legitimate need underneath "can we convert points to time?" is real: someone wants a date. The right answer is velocity. Velocity already maps points to time at the team level, accounting for the team's actual delivery rate, the meetings they actually have, the on-call rotation, the holidays. A conversion table can't do any of that — it just multiplies points by a number that pretends none of those things exist.

The follow-up question: "but how long will this take?"

Pick a date range from velocity. If your team has averaged 30 points per two-week sprint, a 60-point story is roughly two sprints, and you should communicate it as "about a month, depending on what we hit." That's a date that has the team's noise built into it. A points-to-hours conversion gives you a date with no noise, which is wrong with more confidence.

The conversion that's actually useful

Track velocity. Project from it. Recompute it every few sprints. That's the legitimate version of converting points to time, and it doesn't require any conversion table.

Adjacent: story points vs hours covers the same trap from a sharper angle; how many points per sprint covers velocity.