Sure, comes from a prevailing view that estimating is bad. But it's only because estimating is treated like the answer, then we just go with that answer.
The best scrum teams I've worked with maintain a very important survival notion: We don't know the full minimum survivable solution today, but that's ok because we do know enough to get to tomorrow at least. We survived another day. Point is, estimating was never meant to be an answer. It was just meant to kick off discovery. And that's a great way to start because humans tend to be exceptionally good at quickly comparing things for difficulty and complexity. It's an instinctive survival skill.
Ultimately, well after estimating this scrum team will do an implementation (tasking) plan in hours if needed during sprint planning. They will compare that plan against their team capacity plan in hours. If the implementation plan blows out the cap plan by say, 30% then that's a warning sign and they'll tell the PO they need to drop a story for the upcoming sprint. If the cap plan compared against the imp plan shows a 30% surplus, then they will pull in a stretch story and bump their velocity, or won't tell the PO and maybe go play golf at the end of the sprint.
So the story pointing exercise just gets the team some data that helps them get to the next day (survival speak). There's still a lot of story refinement to be done, before they will tell their PO a story is ready to be pulled into one of their sprints.
When teams pull in stories to their sprint backlog, the team is committing to get that story done, so they need immediately actionable data on what's going on at every standup. If the burndown was done in points, the graph ends up looking like a straight line for days with sudden dropoffs toward the end of the sprint - that hides problems. So a sharp team will use task hours instead. Makes the plot a lot more actionable from day to day.
No, the prevailing view is estimating in hours is bad, hence the push for estimating in t-shirt sizes or other stand-ins for task complexity.
The survival terminology is really off-putting. And what’s the obsession with golf? This doesn’t sound like any scrum team I’ve worked with or would want to be a part of.
Well, a rather xor response, but that's ok. Let's go a different route: Someone is using a diet change (fixed), and the elliptical machine to lose weight. This person has no exercise background. The elliptical routine is basic - same program, one hour a day, 8 weeks. BF test is done at the end of each week. Graph the results. What do you think the plot will look like? Why did the subject's weight loss stall out?
Estimations are meant to be exactly that, estimations. Don't try to make them anything else. They offer a grey answer, so use the best tools you have to deliver that grey answer. In this case, it's simply comparing challenges for size, complexity, etc. Don't try to do estimations in a different way just because you want an immediate answer. Estimations are meant to be a starting point to get to a minimum survivable solution. That's how humans use instinctive tools that use the least amount of energy to get to a point that they can survive a challenge. Think about the elliptical example.
In scrum, estimations are the conscious way to get this discovery kicked off; they aren't meant to be an answer, because you don't have enough data yet for a solution. They are meant to be a starting point. Iterate to the solution. When you think you have enough signal for a solution (the sprint), do your final check and balance, which is a tasking plan in hours, during sprint planning.
Another example: The year is 1929, and you're asked to guess the weight of the Empire State Bldg before construction has even begun (1931). What answer delivers more survival information? 180,000 tons, or this: "Well, we know each floor is going to have x concrete, y steel, but not sure about the other construction materials. So it will be something like (x+y+?)*#floors. If your life depended on it, which answer would you go with?
You are looking for a number, and that's why people don't understand what estimating is about. The incorrect approach is like, "Well these estimations are crap, so let's change the estimation methodology." Yeah but it's still and estimation, and you already have a great instinctive tool to make those estimations via relative size comparison, which can be done so quickly, it could literally save your life. Instinctively, we accept that, conscoiusly we don't, so we turn into ill tempered Veruca Salt.
Regarding the golf reference, I'm from Florida. Sorry if the attempt at levity was weak.
I don’t follow this?
The arguments against estimates in hours are well known as this point.