Scrum - Part III: Estimation

This is a continuation of series on Agile/Scrum, where I'm trying to dissect some of the standard ceremonies, and go over their trade-offs on typical teams and tasks.

This time I'd like to talk a bit about task estimation. I'll leave aside the units for now, be they story points or plain time estimates, as this merits a discussion of its own (my examples will use story points though). I'll also park factors such as long-term planning, as they also justify their own post.
The question we want to answer here is simply this: if I'm at sprint X, how can I understand well the effort required for candidate tasks in sprint X+1?

Scrum provides a number of ways; the most popular tends to be planning poker. These tend to be a part of backlog grooming, and involve participation from the entire team. As always, these are described better elsewhere, but the upshot is that the entire team estimates each task (usually independently), and any major differences are discussed and reconciled.

In principle, this is a great approach, as it helps removing personal bias and gives more people chance to comment and uncover potential pitfalls and challenges.
However, when applying it to diverse teams, I've been hitting a variety of challenges:

• Subject matter experts. If we're looking at a specialised task (say, "design an SNMP trap processor for an IPS device"), then can safely assume that not just everybody can understand the effort involved. If we have one guy in the team who has done SNMP trap processors in the past, then his estimate would carry more value than the rest of the team combined.
• Wide range of expertise. Even assuming we deal with a fairly common task (e.g., "add auto-tests to increase module A's coverage to 95%"), we still need to account for different expertise levels. A senior developer might have written hundreds of auto-tests in the past and probably has worked on this specific module. A junior developer might not.
• Different cost per individual. By the same token, even if both the senior and the junior developers understand well what it would take to implement the task, they still might have different figures and both be right. In my auto-tests/code coverage example, the senior developer can estimate the effort at X, the junior at X * 2, and both will be perfectly correct. After all, individual developer productivity can vary up to a factor of 10, and there are reasons why people get paid differently at different career levels and capabilities.
  So, there is no such thing as an absolute task estimate, same way as there is no absolute weight for an object. Weight depends on the gravity force, and a task estimate depends on who is going to work on it.
• Module teams. When a team consists of people working on different projects over the course of multiple sprints, we can hardly expect each and every one to have strong knowledge over all the projects involved. The estimate from someone in the midst of a given project tends to be more valuable.

Let's take my multimedia player example from the previous post. We eventually arrived to this backlog in the order named:

• Prepare high-level effort estimate for porting to the MacOS platform.
• Address 3 visual defects.
• Integrate Chinese UI localisation provided by an external agency - start development and QA planning
• Support two more codecs. - start development and QA planning
• Enhance skin support for more customisation.

We still have the same team  of 6 guys on a project: two UI engineers, two QA and two back-end/middleware developers.

Now let's do a bit of planning poker simulation. First, everyone looks at this task:

• Prepare high-level effort estimate for porting to the MacOS platform.

One person in the team did porting to Mac, so he puts an estimate of 13 story points. Everyone else raises a '?', QA abstains.

Now, we move one to: 

• Address 3 visual defects.

The UI guys and QA show 2 story points, the middleware developers abstain.

• Integrate Chinese UI localisation provided by an external agency - start development and QA planning

Here we might get any spread from UI developers depending on whether they had to do Far East l10n, and same with QA. We might get the same number if and only if everyone has a similar level of experience.

We won't go through the rest of them, but this should give the general idea.

So, how would I go about planning something like this? 
The key goal is: give a chance for everyone who can contribute to the estimate to do so. 

This is not necessarily the entire team! If it's almost that, then that's fine - an "official" practice would work. However, even in the most "Scrum"-friendly scenario, as above, this is rarely so.
Hence, in that specific case, I'd probably ask of the middleware developers to estimate their tasks, UI developers to do the same, similarly for QA, get both UI and QA to plan defect fixes, and then review/discuss each in their own small forum. 
As we have different levels of experience, already decide at that point who is likely to work on what and which estimate we take.
Finally, present the overall estimates and plan to the entire team, but not use it to do the initial planning, just as a sanity check in case we omitted to consult with someone.

With of all of that, we still maintain the main principle: the people who are going to work on the tasks, do their own estimates. On the other hand, we also have efficiency: we minimise overhead from the estimation process and gather it from the people who are best placed to contribute.

Lastly, you might be viewing my example with a healthy dose of skepticism. Five user stories across six people, including big unknowns (e.g. port to Mac OS)? It does not matter what tactics you use, the sprint will go sideways!
All true, and I'd like to tackle this later on by talking about long-term planning. The purpose so far was to keep examples comprehensible; if I were taking real-life small tasks, we'd spend too much time explaining their technical background.