You check the clock. You check again, because you didn't actually read the time because you were too absorbed in the process of checking the clock that you forgot to check the clock.
You check the clock again. You have a new email. You consider checking the clock again, but give up and accept your fate because checking the clock a (second? Third? Tenth? First?) time is just too much right now, you're already running late anyways so it was kind of all procrastinating in the first place. You don't even know what you were supposed to be checking it for. Just wait and see, it's probably not that important. Maybe you'll check the clock and see if it sparks your memory.
You check the clock. You finally see the time. The bus drives past you.
When I teach story points (not in an official Agile Scrum capacity, just as part of a larger course) I emphasize that the points are for conversation and consensus more than actual estimates.
Saying this story is bigger than that one, and why, and seeing people in something like planning poker give drastically differing estimates is a great way to signal that people don't really get the story or some major area wasn't considered. It's a great discussion tool. Then it also gives a really rough ballpark to help the PO reprioritize the next two sprints before planning, but I don't think they should ever be taken too seriously (or else you probably wasted a ton of time trying to be accurate on something you're not going to be accurate on).
Students usually start by using task-hours as their metric, and naturally get pretty granular with tasks. This is for smaller projects - in larger ones, amortizing to just number of tasks is effectively the same as long as it's not chewing away way more time in planning.