How to deal with outlier programmers during sprint planning?

Question

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?

Answer 1

Estimation (e.g. story points) is done based on the time and effort of a typical programmer. When you are calculating velocity, you go by a team of typical programmers. This is done for several reasons:

1. The highs and lows should average out. Maybe you have one rockstar, but odds are you have a knuckle-dragger too. Or two below average but not terrible programmers.

2. Even the best developers get stumped sometimes. I have seen awesome programmers take half the time on every task, then hit that one brick wall where a 4 hour task takes three days. Maybe it was due to an unforeseen difficulty, maybe the developer was going through personal problems, maybe he came to work hung over. Who knows. It happens.

3. Velocity can change based on previous sprints. If you know you can do more than you think, maybe you should plan for it (but not necessarily, see my next point).

4. None of this really matters, because if you get ahead you can always pull in stories from the backlog and get ahead of schedule.

Keep doing what you are doing and your other problem will not even matter. If your rockstar accounts for 20% of your team's hours and is on vacation, schedule 20% fewer stories points in that sprint. As long as you are not inflating your velocity, that will automatically compensate.

The key here is you are not just looking at each iteration in isolation, but scheduling the entire project one iteration at a time to help even out the irregularities that inevitably occur.

Answer 2

All sprints are not created equal and great programmers have influence beyond their own keyboard.

This is only a problem if you expect all sprints to have the same amount of work completed. If everyone is present the first 5 sprints, you're going to have to adjust eventually when anyone leaves and yes, especially the best developer.

Great programmers leverage their expertise in a given project way beyond the actual code they write. They influence other team members and the overall design of the project. Some of this gets hidden in a project. How do you measure all the things the team decided "not" to do because of the experience of the better programmer?

Over the course of time, you may discover this low-level of productivity when your best programmer is absent. Other than confirming your evaluation of this person, what else have you gained other than on a couple of sprints a year, you're going to get less done.

Answer 3

I think the best answer honestly is that there's no good way to account for this. It's kind of a "there is no spoon" situation, though. This is only truly a problem if you're putting more weight to velocity than what it actually holds. Velocity is an estimation of how many story points a team can do in a sprint. Story points are an estimation of effort involved, which is based on previous estimations of effort for what you estimate to be similar tasks. In other words, it's an estimate of an estimate of an estimate of an estimate, and it's pretty much exactly what your grade school math teacher yelled at you about when you introduced rounding errors in set of calculations.

The long and short is that velocity is better than having no idea, but frankly not much. You can use it to forecast completion dates, because management likes hard dates, but it will always be just a forecast, and if you've ever carried your umbrella around with you all day on the sunniest day ever, you are fully aware that forecasts are often wrong. If you end up with leftover work at the end of the sprint, that's okay. That may be a crazy concept, but it's something you can cover in the retrospective and learn from to better estimate in the future. The team didn't fail; they just were off on their forecast. If you run out of work before the sprint is over, you can always just throw other backlog items in. Just because you didn't think you had the capacity, doesn't mean you have to just stop when the sprint backlog is empty. Treat velocity as the fragile measurement it is, and just don't worry about it.