In scrum you are traditionally not meant to give time based estimates(it doesn't work). You use story points. Humans are bad at time estimates, everyone is.
Using story points, you measure how complex a story is, rather than time. A small spelling change, vs massive re-architecture. You do things in general abstract terms, rather than hard deadline, where you get fired if you don't meet it.
A added advantage of story points is that is abstract, it doesn't care if you 6 hours out. So you don't feel pressured to lower it.
You then look at previous sprints and see how many large/small tasks you can complete in a sprint.
A lot companies try to use time estimates to increase productivity, and get developers commit to releasing by a certain date. It doesn't work, it leads to rushed buggy code.
Its sounds like company is one that doesn't really understand agile/scrum, and is trying to use estimates as a whip to get you to work faster.
Companies need to stop using time estimates as a whip, and focus more on methods that are actually generally accurate, and provide useful information for planning.
Split work into small enough tasks that they are all max 1 day if at all possible, meaning that everybody on the team knows what should be done and can just "go-go-go". Much easier to estimate.
Always remind yourself and your team about any work ouside the core functionality being implemented. Database migrations, deployment costs, documentation needs, unit- and functional tests (both updates and new), technical debt that needs to be fixed now, and if there are other risks like hitting resource limits or missing performance targets.
Keep track of actual outcome vs estimate. What was the main reason it took longer? Best done if working close to co-workers on tasks, making progress or lack of it associated with the team and not individuals, where it could easily become a blame game.
Be aware of how much distractions you have from doing actual development. Meetings, urgent bug fixes or help with other problems in production, customer contact, supporting sales, etc.
I wrote up last month how I became good at estimating time.
http://rachelandrew.co.uk/archives/2014/06/20/how-to-become-...
TL:DR you need to start tracking your time and noting when your estimates were incorrect. Fairly quickly you get to a point where you can see the places you tend to make a poor estimate and adjust them.
+1 to smaller tasks. You gotta break it down.
I've also stopped estimating. When the tasks are kinda vague and open the estimates are just wrong.
I've been trying to follow patterns in the Toyota Production System and those from Personal Kanban (books). If I do happen to estimate (oh, that's like 2 days) its less of a deal, I'm just blocked till done.
Try to keep the team either full (3wip) with 1 blocker. That's what a moving pipe looks like to me.