I’ve been quite adamant lately that story points are about time
Two developers can start by estimating a given user story as one point even if their individual estimates of the actual time on task differ. Starting with that estimate, they can then agree to estimate something as two points if each agree it will take twice as long as the first story.
When story points equated to hours, team members can no longer do this. If someone instructs team members that one point equals eight (or any number of) hours, the benefits of estimating in an abstract but relatively meaningful unit like story points are lost.
When told to estimate this way, the team member will mentally estimate first in number of hours and then convert that estimate to points. Something the developer estimates to be 16 hours will be converted to 2 points.
Contrast this with a team member’s thought process when estimating in story points as they are truly intended. In this case, team members will consider how long each new story will take in comparison to other stories. You and I might agree this new story will take twice as long as a one-point story, and so we agree it’s a two.
However, you might be thinking that’s five hours of work, and I might be thinking it’s 10. In this way, story points are still about time (effort), but the amount of time per point is not pegged to the same amount for all team members.
If someone in your company wants to peg one point to some number of hours, just stop calling them points and use hours or days instead. Calling them points when they’re really just hours introduces needless complexity (and loses one of the main benefits of points).