It is generally accepted that the best programmers produce at least an order of magnitude more than average ones. This seems like it would cause problems with the usual approaches to sprint planning that focus on whole-team metrics - mostly around estimation and velocity.
For estimation, the great programmer is likely to vote differently than the average one. Ideally, the team is using story points, so the programmers are more likely to agree about the "relative complexity" of a story, but even there, the great programmer is more likely to know a tool/trick that will allow them to simplify the problem. The team will generally vote as a whole and average/majority wins. That solves the inaccurate estimation - unless the great programmer picks up that story.
"But that doesn't matter!" I hear you say, "The great programmer just gets more story points done per sprint". Which brings us to problem #2. Velocities are very often measured for the whole team, not individuals to help even out the variances from sprint to sprint. The velocity is then used as a sort of rate to account for vacations, meeting times, etc. The problem comes that the great programmer disproportionally impacts the team velocity. If they're on vacation, far less work will be done than expected by velocity calculations. If an average programmer is on vacation, more work will be done than expected by velocity calculations.
So how to deal with this sort of inequity in performance during sprint planning? Some sort of weighting effect? Just let the errors occur and even out over time?