Iteration has already started, new programmer joins the team, task X has already been estimated to be 30 hours by a different developer.

What is the best practice in this situation?

  • new developer runs with the given estimate (the idea being that any discrepancy will be corrected for when velocity is calculated?)
  • new developer re-estimates task? (if so, what if it's significantly higher and no longer fits in the iteration?)
  • throw our hands up and go back to waterfall?
  • something else entirely?

What I say is:

New developer re-estimates the task. If it has to be moved out of the iteration then it gets moved out.

You don't know if the new developer is going to be able or not to do it in the time the original developer though it will take. And with agile methodologies is the developer that does the work the one that should say how long it will take.

Furthermore, I would apply a multiplier (how big depending on the developer), as the developer has to fit into the team/project/company.

| improve this answer | |

I would not add this person to this individual sprint. Instead give him another task to work on to get up to speed on the codebase (low-hanging bugfixes perhaps?).

Adding a new person to the team will likely slow down your progress on this particular goal since he will have to get used to your environment and learn how things work there. Incorporate him into the next sprint, with proper estimates based on the new team.

| improve this answer | |

First off, I hear "Agile Task" and I think one to two days' work, not a week's. Tasks are what you break stories into when the story itself fits in the iteration, and it's a real rarity to have a story that cannot be broken down into smaller pieces.

Second, you're basically asking this new developer to hit the ground running. If he can be reasonably expected to jump right in and keep up the pace of the rest of the team, then the original estimate should hold. If he can't, he probably shouldn't be held to this estimate, at least not by himself.

Third, what's the situation? I'm pretty sure the situation was not that the team estimated their work, then someone walked out and you replaced him the next day. So, I'm thinking X guys on the team estimated this sprint's work and took in what they thought they could handle, and then you introduced the new guy and now there are X+1 guys to do the work originally committed to by X guys. Unless the team didn't pick their workload, and instead had the backlog crammed in by management, I would not be giving the new guy much to do this week. If the schedule was set by management, it's not Agile.

Personally, I would set this guy up to pair with a more experienced programmer for his first sprint (if your programmers don't pair all the time, which I'm inferring they don't from the fact that you're considering giving one task to one guy). By looking over his shoulder and asking questions, he'll start to learn the codebase, and if his general programming skill is up to snuff he'll be an effective code reviewer almost immediately, spotting bugs, inefficient code, etc etc.

| improve this answer | |
  • Unfortunately the situation was pretty much that - someone estimated the work then we lost a good amount of manpower. Now new manpower has the tasks that were estimated by old manpower. – user53737 Jun 19 '12 at 14:50
  • 7
    That's an exceptional case, and in that case I would have the new team (not just the new guy) re-estimate the backlog. I would also consider cancelling the sprint; if half your team left mid-sprint it's no longer the same team, and shouldn't be expected to meet the goals of the old one; they'll have a new steady-state velocity and a different way of looking at things. – KeithS Jun 19 '12 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy