How do I better plan my work during sprints?

Adding to Alex's answer, there is often "invisible work" that engineers do -- a common source of getting over-committed is that engineers don't anticipate (or at least they don't verbalize) the other parts of their job. Things like documentation, on-call load, team meetings, ad-hoc data requests, etc.

Use that to justify why you should take on less work, but do it with higher quality.

I assume your sprints are 2 weeks, but I still recommend checking out this Q&A about how to do better estimates: "How can I get better at estimating long-term projects?"

The key idea here is to "Underpromise and overdeliver". Don't only factor in coding time for a task - Even if there's no formal planning prior to execution, you need to account for code review time.

If you're seeing a lot of spillover, this means that your estimates are too aggressive, and you can probably be more proactive catching future issues. I recommend this Q&A for advice on how to improve there: "One of the projects I’m leading has a lot of thrash. How can I smoothen execution on future work?"

Even for a smaller task (<1 week), it can pay huge dividends just thinking through the task and writing down your high-level thoughts and strategy on it for ~1 hour before writing any code. This is a behavior I see many earlier-in-career engineers need to learn.

If folks on your team are pushing back against your more reasonable estimates, please let us know, and I'm happy to share advice on that as well!