How do you deal with a team that uses "Agile" and equates story points to hours?

I hate these kinds of teams - This was my life earlier in career. Ironically, any engineering organization that is very gung ho about being "agile" is almost certainly not agile and is actually just steeped in Jira politics and bureaucracy. The companies with the best engineering culture tend to give their engineers a lot of flexibility and autonomy: This is a core reason why Big Tech companies are so renowned and successful (pretty much nobody at Meta used Jira).

As Jonathan mentioned, I recommend shielding yourself by adding a lot of buffer to tasks (I think +50% is a good range, so turn 2 weeks into 3 week ones for example). You want to add a good amount of buffer anyways to help guarantee code quality, and this buffer also lets you negotiate down when people come knocking to shave off your story points.

I talk in-depth about estimating tasks well here: "How can I get better at estimating long-term projects?"

If stakeholders are too aggressive pushing down your estimates to the point of insane austerity, firmly (but politely) push back using the tactics here: "What are good strategies to push back when the deadline is not realistic?"

Another option is to see if you can change the overall process to be more engineer-friendly. It's not likely to succeed, but it's worth trying. When it comes to actually conducting an engineering team effectively (i.e. empowering them), I recommend the principles here: "How do I optimize my sacred hour at work?"

And of course, if it gets too bad, try to switch teams/companies. Easier said than done of course (especially in this economy), but at the end of the day, no job is worth your mental health. Here's our masterclass on how to find a genuinely good team: [Masterclass] How To Choose A Good Company And Team As A Software Engineer

This type of failure mode usually occurs when someone in charge of the project is solely responsible for "project management" tasks (basically cracking the whip and coordination) and usually detached from the (engineering) domain itself. If this is the case, I'd suggest bringing it up as a topic in a 1-1 with someone more senior in your engineering org, which usually is your manager/skip level. Otherwise, it's worth examining the underlying motivations/incentives of the person insisting on this (it's quite rare from my experience that someone more senior on the engineering ladder like a staff/principal would approach estimation this way)

Frame the conversation to get more informed inputs to estimates, thereby making the project delivery smoother. Mention that estimating technical tasks, especially the more complicated ones, need strong technical input. Be open to having another (more senior) engineer weigh in on the complexity and the "story points", but draw a firm line that it cannot be unilaterally decided by someone outside of the engineering function. Additionally, once the estimate is set, mention that it is counterproductive to go back on the estimate to "squeeze more juice out" when there is no change in scope / new material information.

On a personal note, during the early stages of building my engineering team, I had to go into each project that experienced the same challenge and course correct. Over time, it's important to enable others on the team to handle the situation appropriately without my direct involvement. Getting alignment from someone senior in the engineering org is a key first step to moving in the right direction.

This type of failure mode usually occurs when someone in charge of the project is solely responsible for "project management" tasks (basically cracking the whip and coordination) and usually detached from the (engineering) domain itself.

💯💯💯

In general, if there's a major stakeholder (i.e. they hold decision-making power) on the engineering team whose title is "Scrum Master" or "Agile Coach" but they are completely non-technical, it's not going to be great.

My previous company went though a similar phase when we went through an agile transformation: I ended up just saying "42069 story points" every time an estimate was needed from me. Eventually, people just caught on and left it alone. This definitely won't work for your use case, but maybe you can overestimate your story points for each task to bump the number higher. Or if you're feeling risky and want to throw some satire in the mix, you can give yourself 1 single simple task (like a copy change) and assign it a large amount of story points (like 50000).

Having worked in both such "agile" and big tech "not so agile" environments, I can say that one can excel in both the envs.
They simply need different mindsets, and a willingness to find motivation and do good.

Big Tech / Flexible Environments:

The SWE needs to be skilled at time and project management, and driven to prototype with new ideas.
SWE defines a lot of their priorities on their own (esp. so for more senior SWEs).

At the end of quarter / year you are evaluated on the impact you landed.

Its highly encouraged for the SWE to find more interesting and important problems that need to be solved.
These might be product, process or technical debt related, etc.

Strictly Agile Environments:

There is a dedicated Project Manager / Scrum Master who enables the team to be focussed and deliver on time. There is additional overhead to create tickets, plan story points, evaluate velocity, do retros, etc.

In such environment, a strong staff / principle engineer breaks down the complicated problems to small and very small size chunks which can be solved in 1-8 hours and then files tickets for them. Now, these tickets are divided among other engineers, prioritized and individual/team velocity is measured accordingly.

Agree, as a junior engineer, it might feel like being a small cog in the wheel of an assembly line.
But, this leads to great opportunities to grow as well:

1. Get better at task breakdown
   For every task assigned to you, create a plan and try to subdivide it into very small tasks. Think of you being assigned an intern who will be doing these hour long atomic tasks and the text you write is clear enough that they don't need to ask you on how to do it anymore. Once you are so good at this, and each task indeed takes you 1 hour, try to do this for more and more complex problems. If these subtasks are taking you longer than 1 hour, break it down further.
   Also, if you have done this breakdown beforehand, you know for sure how much time its gonna take. And with that, the Scrum Master won't be able to push you to reduce the points / hours on it without asking you to maybe remove some subtasks from it.
   Further, as you practice this skill, aim that your hour long atomic tasks get done in 45-50 mins max. If your atomic tasks are taking longer than 1 hour, learn from it and break it down further the next time.
2. Find some interesting large project / problem. Document it, explaining the benefits, risks, scope, resource needs, etc.
   Get this approved by Product and Engineering managers, etc.
   This is what a staff / principle does, but you as a junior eng can do this too for a project that you are proposing.
3. Find patterns in the atomic tasks that you / everyone in the team is doing repeatedly.
   - Maybe sending an email after a release is cut, or
   - Syncing latest code and restarting server, or
   - Finding production objects and replicating them to create mock objects for testing, etc.
   
   And see if you can automate / write scripts / batch them to simplify any of this?
   Essentially, if your team was able to do 100 story points last week, what can you do / help so that the team does 150 points next week?
4. Create tickets for yourself which are related to your own learnings / explorations / prototyping.
   Story point these, and get them included in your sprint.
   It might be as simple as, I will spend 3 hours reading this whitepaper on Friday and put it on your Kanban board.
   I am sure neither your Engineering Manager nor project manager will have a problem with this.
   Rather, they would appreciate if you could present learnings from this whitepaper to the team.

NOTE: We try and not modify current sprint.
So, plan your next sprint today and get at it so good that you don't have to modify your sprints mid-way. :)