In the "right" use case, story points should just represent relative effort.

The hours dont matter, its more about ranking how challenging a task is, in order to help the manager rank the priority of tasks.

You should have typically 2~3 metrics:

1. Points, which represent relative effort of the task to the other tasks you are also ranking.

2. Value, how much value does doing this task provide, how important is it

3. Risk, how risky is it that this might break shit though if you make these changes (IE new features typically are low risk since they just add stuff, but if you have to modify old stuff now your risk goes up)

If you have a good integration testing system automated, Risk can be mostly removed since you can just rely on your testing framework to catch if something is gonna explode.

Then your manager can use a formula with these values to basically rank a priority order for every ticket you now scored, in order to assess what the next thing is that is best to focus on.

The point is that if story points=hours, you should just fucking use hours from the beginning.

Story points are evil because they were intended to help teams set achievable goals but are almost never used as such. Once a manager catches wind of this practice, they will bastardize it into a pile of shit most high. Scrum doesn’t prescribe this practice so ditch it. Reject it and move to something only the team members will understand. If you move to relative animal sizes or some shit and you meet your goals, managers can fuck right off.

That depends on your team composition. Decoupling story points and hours means that the points indicate the complexity of the task; each developer might take a different amount of time to deliver that depending on their ability and expertise in that part of the system. The points give you a simple metric to show how much complexity the team have left to deliver, and tasks get assigned to whoever is best placed to deliver them at the time.