Story points answer a relative question
Story points are useful because they ask the team to compare work against other work, not predict a personal stopwatch result. A five-point story should feel larger, riskier, or less certain than a three-point story for this team. That relative comparison is exactly why planning poker can reveal hidden assumptions: two people may both be skilled and still see different risk.
Hours still matter, but for a different conversation
Hours are not wrong. They are the right language for calendars, support rotations, pairing plans, handoffs, deadlines, and near-term capacity. Trouble starts when a team uses points while secretly asking for hours. If the real question is whether the work fits before Friday, say that directly and talk about availability, interruptions, and confidence.
Where teams get into trouble
Teams get distorted estimates when they convert every point into a fixed hour range, compare individual developers by velocity, or treat a point estimate as a delivery commitment. Those habits make people defend numbers instead of explaining uncertainty. The healthier pattern is to use points for backlog sizing, then use capacity conversations to decide what can responsibly fit into a sprint.
A practical rule
Use story points when deciding how large or risky a backlog item is compared with known work. Use hours when planning a specific calendar window or coordination constraint. If a planning poker round keeps turning into availability talk, pause the estimate and name the capacity problem. The team will make a clearer decision when the two questions are not collapsed into one number.