So, like other commenters have told you - you're very fortunate.
I've gone back & read the article that you reference, and while it makes a valid point (estimates are often used as a stick to beat the developer with), the logical conclusion is frankly, illogical (don't estimate).
That's like saying you keep losing at poker with good friends, so you stop socialising with those friends.
The Project team (PMs, PMO, call them what you will) have a very specific need - to communicate when feature X is likely to be with end users. It's also their job to manage expectations, and to allow for slippage etc, though many of them tend to forget that part.
So our take, is that developers put story points on things, to flag "how complicated we think this piece of work is, compared to another piece of work" - story points do not, ever equate to time. The estimate is, as that article suggests, usually wrong. So we don't have a problem with adjusting it when we get better information.
From there, since we use Jira, PMO have a button they can press that says "how many points per sprint do we achieve" - and then it's relatively simple maths to average that across a number of sprints.
So then, in Sprint planning, assuming all tasks have a "complexity estimate on them," Sprint Planning becomes a drag-drop exercise, and if the backlog is groomed properly by a Product Owner/Stakeholder/vaguely interested party, they simply drag the things from the top of the backlog into Sprints, can plan 6 Sprints in advance, and they know the time box that fits around a Sprint.
Heypresto, stakeholders know how long features will take to be in front of end users (with PMs managing that expectation in case of unexpected issues).
Then, and this is the part most companies get wrong, it's my job as Dev Manager to monitor the whole shebang. Are the team overfitting estimates in order to relax? Are the PMs pushing too much into Sprints? Do the git statistics match the complexity statistics? Etc. Etc.
But again, you're lucky, you don't have to deal with any of this.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That is what I do. My jobs are in the real world
So, like other commenters have told you - you're very fortunate.
I've gone back & read the article that you reference, and while it makes a valid point (estimates are often used as a stick to beat the developer with), the logical conclusion is frankly, illogical (don't estimate).
That's like saying you keep losing at poker with good friends, so you stop socialising with those friends.
The Project team (PMs, PMO, call them what you will) have a very specific need - to communicate when feature X is likely to be with end users. It's also their job to manage expectations, and to allow for slippage etc, though many of them tend to forget that part.
So our take, is that developers put story points on things, to flag "how complicated we think this piece of work is, compared to another piece of work" - story points do not, ever equate to time. The estimate is, as that article suggests, usually wrong. So we don't have a problem with adjusting it when we get better information.
From there, since we use Jira, PMO have a button they can press that says "how many points per sprint do we achieve" - and then it's relatively simple maths to average that across a number of sprints.
So then, in Sprint planning, assuming all tasks have a "complexity estimate on them," Sprint Planning becomes a drag-drop exercise, and if the backlog is groomed properly by a Product Owner/Stakeholder/vaguely interested party, they simply drag the things from the top of the backlog into Sprints, can plan 6 Sprints in advance, and they know the time box that fits around a Sprint.
Heypresto, stakeholders know how long features will take to be in front of end users (with PMs managing that expectation in case of unexpected issues).
Then, and this is the part most companies get wrong, it's my job as Dev Manager to monitor the whole shebang. Are the team overfitting estimates in order to relax? Are the PMs pushing too much into Sprints? Do the git statistics match the complexity statistics? Etc. Etc.
But again, you're lucky, you don't have to deal with any of this.