I used to ask this to the annoyance of everyone too. I stopped awhile ago and have learned to embrace the suck of it.

I am convinced that 'story points' have been made vague and hand-wavy, because stakeholders would take an engineer's time quote at face value. Then the quote of 'two weeks' gets passed up the chain. Then some marketer or sales person makes promises or media buys based on this quote, and then when the date slips, and the engineer was asked why, they got a jargon-laden shovel-load that was of no use to anybody.

Heads rolled shortly after. Story points were born to protect the other middle-management wastrels from a similar fate.

So now 'features' are only reported in 'release notes' that happen after a sprint. 'when is it done?' can be answered with 'this sprint or next, most likely, as long as our velocity holds during this epic' -- a rich and blameless pile of nonsense that anyone with firing authority cannot possibly act upon.

Nobody ask engineers when things will be ready ever again.

Engineers can read YC during their workday as long as that magical 'Team Velocity' stays high enough every two weeks. You can even play Dyson Sphere Project on days 1-13 and sneak a heroic bender of pull requests across the line the night before sprint end, saving the sprint, champion to all.

All forecasting can and will be expertly sandbagged by the engineering team. Nobody can accuse them of collusion because they were independent votes using scrum poker or some other web toy. We all said that one-word text change was a 2 point ticket, boy howdy, so it surely must be. We're the ones doing the work after all, and 2 points doesnt mean squat anyway in a temporal sense, so what is there to even question or argue about? FINE, TWO. next!

My advice, OP, just let it go. Embrace the nonsense of it all. Let those 'stakeholders' justify their existence and have their plausible excuses that preserve their jobs. We can work on side projects or new steam releases in peace for most of our corporate existence.

Also, some bonus tips I learned for voting:

1 is never the right answer, or everyone will need to discuss consolidation potential with other tickets, which never works, but can kill hours with pointless discussion and debate -- time far in excess of the the work itself.

2 is okay, unless everyone else went 3, then you're just being a cocky prat.

3 is the default vote for all things big and small.

5 is okay, but risks elaborate "let's talk it out and pre-engineer the thing while virtue-signalling that I'm a very thought-provoking team member" sub-sessions. These are to be avoided unless you want to pre-engineer and virtue-signal the thing. Quicker and easier to vote 3 and just ask to take that ticket if you're so interested.

8 is right out, or everyone will need to discuss where and how to break the thing apart and usually you earn a second grooming meeting.

13 is a super hilarious sarcastic vote for that one-word text update, but you can only use it once, mister or miss funnylaffs. Then we roll our eyes because of the re-vote it causes.

The game is only won by getting out of grooming/sprint planning meeting as quickly as possible. That's now your entire productivity goal at Big Dumb Agile Company. Enjoy. :)

- Mike also.