Personality conflicts and process diseconomies are clouding the real issue. Tracking the proper performance metrics will improve your overall process and provide guidance for addressing issues of team composition.
Your Problem Isn't Estimates
[O]ur SQA resource...overestimates everything.
So what? If your team is using planning poker, or any other commonly-used tool for building consensus estimates, then this person's estimates are simply outliers. See How should a team handle disagreements about story-point estimates in Scrum? for various ways to deal with this issue.
Estimates are not commitments, and velocity is just another estimating tool, not an end unto itself. As a result, the Scrum Master should encourage the whole team to estimate the task as accurately as possible during Sprint Planning, and then move on.
What Estimates Are Really For
In the end, though, this has nothing to do with estimation. Scrum estimates are "educated guesses" about the level of effort required to do something. The value of estimates lie in in the confidence interval your team is able to assign to estimation-accuracy over time.
Estimates are explicitly not management targets, and neither is velocity. If you're using them this way, you will not achieve your team objectives.
Some of the Problems Are Personality-Based
"This is how much time I have to do this, and once I am finished, I can spend the rest of the time dozing!"
This is speculation on your part; you are imputing motives. It indicates that you have an adversarial relationship with this person, and you need to own 50% of that.
If you set aside your personality issues with this person, your underlying concern seems to be that you think this person is lazy, not pulling his weight, or not meeting your expectations for efficiency. However, planning poker (or other estimation tools) will not help you address any of these concerns.
Your Solutions Should Focus on Performance-Based Process Improvements
Once you accept that your issue is not the estimates, but in your perception that this person is not performing adequately (for whatever value of "adequate" you care to apply), then you will free yourself to address performance concerns without clouding the issue.
[Our process] allows him to do so little work that the other team members need to end up doing work that he should have completed as part of the over all release, so instead of being able to pull extra development features off the back log they/we end up doing sqa stories.
Your process needs improvement. Whether the person is actually a bottleneck or not, if the process doesn't enable you to refactor your work-flow or adjust resources to remove resource constraints then your process is broken.
For example, if all SQA work flows through this one person, this may not be an optimal process for your team regardless of who fills that role. If the person performing SQA work isn't able to deliver sufficient value within each Sprint, you can do any of the following:
- Limit work-in-progress (WIP) until the capacity of your process is not saturated.
- Add additional capacity to your process. Examples might include adding more SQA resources or replacing inefficient personnel with more productive team members.
- Adjust project delivery dates to align with actual throughput instead of management-defined targets.
- Refactor your organization's hiring, compensation, performance review, and retention processes to improve the quality of your team members.
Improving your process will help you accurately measure and manage team member performance. At the end of the day, whether a person's performance adds or subtracts value from the team is what counts, and that's what you should be focused on.