Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?
share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|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. –  Whisker 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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.