I want to be able to plan my work better for sprints, so that I can avoid spillovers or call out anything that might lead to that as soon as possible.
I assume your sprints are 2 weeks, but I still recommend checking out this Q&A about how to better estimate 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 smoothen execution on your tasks and projects.
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!
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.