How do I estimate my sprint tasks better?

6 months vs 2-3 years is a significant time difference, so it is not a surprise that your team mates are much better at estimations (for that particular team scope, not in general, necessarily). It is also possible that they are choosing their 10 story points more strategically with an appropriate mix of easy and risky tasks. So don't be too hard on yourself about this just yet.

Practically, though, here are a couple approaches I can think of for you to improve -

1. Deliberately calibrate yourself during the next few sprints; ie, next sprint, try to pick the simplest, seemingly no brainer set of tasks, and figure out how you do on them. After that, you can take on more and stretch yourself.
2. Lean on one of your teammates that you trust to help you. Perhaps you can either do a post mortem with them on a sprint where you were esp. off with your estimates, or better yet, review your estimates upfront with them before the sprint starts.
3. Lastly, do be proactive about signaling increased complexity/scope in your stand ups as soon as you realize it. That part is ultimately what matters; initial estimates will never, ever be consistently accurate, but "escalating early and often" when things are not going as was initially expected, and then taking action, is what makes for successful outcomes.

Good question, I believe every developer have been struggled with that especially in the beginning of their career or starting in a new team.

One thing that made me wonder:

Epic owners create tickets and they are presented to people. Whoever is interested in whatever tickets, they assign it to themselves...When these tickets are created, the creator assigns an estimated story point value based on their judgement of the complexity of the ticket.

Sounds like the creator estimates the task not you. Is that the case? If yes (I hope not), for me, this is totally wrong. Often it's hard to make estimations yourself when you know yourself very well and know what you are capable of. Now imagine if you have to do it for someone else. This guy should know you really well, better than you. So, someone is setting the pace for the entire team which I can't agree cause you aren't (most likely) at the same level. I can write a lot how wrong for me is this, so I hope this is not the case.

One idea, which adds to one of @Rama's suggestions - since the backlog typically is prepared in advance, check if you can prepare in advance about understanding of some of the tasks. See how good are you in each one of them and act fast later. If your have good relationship with the other team mates, ask them if you can pick those tasks before the planning :)

A ticket a day sounds kind of stressful, I hope they are not all completely unrelated and touching various domains (but maybe this is normal and Idk how most dev teams work)! I struggled with this as well but to piggy-back off of previous great comments, perhaps a way to tackle this is planning ahead the design as much as possible.

My team has been using a 'Technical Design Document' per ticket, where we define in our own words the business needs and more importantly, formulate exactly what needs to be done; which areas of the code, which methods to modify or add, where it fits into the flow, how it affects existing logic, etc, how this will be tested. This has been monumental in getting tickets completed by or before the Sprint (story-pointing and estimating gets closer to accurate and consistent as an instinct for this naturally develops). Formerly, a lot of us just had tickets spilling over every Sprint and it felt like almost nothing was getting done.

When I first started writing my design docs, I felt like I was moving slower and that it was actually impeding my progress. However, what it was actually doing was forcing me to face all of my 'battles' earlier on rather than half-commit through the entire Sprint. (I have also realized that my procrastination is sometimes just out of fear of embarrassment/imposter syndrome! A lot of the scary bits for me has been reaching out to the right domain experts for clarity

I can't remember which Masterclass/vid it was but recall Rahul quoting the SEAL motto, "slow is smooth, smooth is fast", and I think about it often.

I do see my inability to complete the 10 points as a personal failure even if no one explicitly points it out or cares about it.

Don't!

It seems like you have great, understanding teammates. They have given you the very valuable feedback that you're biting off more than you can chew and aren't being mean about it.

There's already enough struggle being a software engineer, especially one that's relatively new to their team. There's no need to invent more problems for yourself. 😄

On top of the already incredible advice everyone has shared, here's some additional resources that may be helpful:

• "How do I better plan my work during sprints?"
• "How can I get better at estimating long-term projects?"
• "How to update in standup if we are spending time coding but are not blocked?"
• Strategies To Stop Procrastination