I'm currently estimating a new project. My high level estimate assuming there was one developer working on it is 25 weeks.
In reality there will be two developers working in parallel. What factor would be reasonable to reduce the estimate by? (I realise that it will not be 0.5)
It depends on how long it takes the new developer to learn the codebase, etc.
Be aware it may not even be shortened at all.
I think that the chance exists that your estimate could increase a bit at first. The new developer has to get familiar with the project, existing developers may need to spend some time to teach him some things about the project, etc...
With all the normal caveats (it's impossible to truly estimate this, often adding developers adds time, etc etc). Assuming the additional developer is of a similar ability level, has a comparable skillset and experience with the platforms/technologies as me, I typically estimate a 20% reduction for adding an additional developer; additional 5% reduction for adding a third. No reduction after that.
There is no answer to this question. It depends on skill level of the developer, knowledge of the project, resources, etc..
In my experience, I assume the first part of the time will actually set the project back as it takes time to catch him up.
If I had to come up with a single number for the sake of this question, I would say -50% for the first few weeks and then +25% for the remainder :)
Depending on the original developer and the new developer, you could reduce that 25 weeks by as much as 75% (no I'm not kidding) or increase it by 50% (again, not kidding). Fact is, there is a vast difference between individual developers. Developers of a supposed similar skill level have shown to vary by an order of magnitude.
It all comes down to the experience level, skillset and domain knowledge of the two developers as well as how well they work together. Some teams (the good ones) are better than the sum of parts. Some are worse.
Generally speaking all other things being equal, you will lose time on communication issues and I'd probably put that at about 20% going from one to more than one.
This depends on way too many factors than is being provided. Can you compare this to another project? How difficult is the project? How many tools will be shared amongst the two developers? How skilled is the other developer? How effective will communication be across developers? Really without any prior benchmarks it is very tough to give a good number.
It depends on the developer you are adding. In the end, only the actual developer can give a somewhat realistic estimation about the time they need to code something. The time you need to code something yourself doesn't have a lot of relationship to how long someone else will need.
I suggest you totally ignore the original estimation, decide how you are going to split up the project between the two of you. Then make new estimations for how long the both of need to complete your own part. Then add time for integration of both sides of the development.
This way you have an estimation based on the input from the developers who are actually going to build the code, instead of just one of them.
It probably won't, at least not if the delivery is due in less than 3 months.
Personally I'd assume that for the first month they'll be essentially negatively productive - they'll do almost nothing of use themselves and take away from the rest of the team asking questions, breaking things and so on.
The next month they'll be close to breakeven, maybe a little better but basically doing and taking in equal measure.
The final month they'll probably make up for what they damaged in the first month.
After that they'll be about as productive as anyone else after 3 months on the project (that is competent but not as useful as the guys who've been on it for longer).
(Note: this assumes that the developers being added don't outnumber those who can productively get them up to speed. Where you're adding, say, two developers to the project and there's only one who can talk them through things you're potentially doubling the impact on the existing guy and halving the speed the new guys get going).
The things which will determine the precise impact will be:
1) technical skills
2) knowledge of the business domain
3) knowledge relating to the specific project
4) size of the overall team, in particular how many extra people are you adding as a percentage
You want the first three to be high and the last one such that proportionally the team isn't changing too much. Add one person to a 10 man team and the impact is managable. Make a 5 man team in to a ten man team and you're probably screwed for 3 - 6 months.
Why is it this way? More people increase the number of lines of communication, lower the average knowledge level, increase the chance something is going to be questioned (and therefore the debate reopened, possibly usefully, probably not), increase the disruption to a functioning team and so on.
I wouldn't just blindly increase or decrease by a percentage - rather I would divide up the estimated tasks between the developers, and ask the new developer to estimate the time he will take on each of his tasks. I would not question any of his estimates unless they are obviously out of tick.
In my experience it is a bad idea to treat estimates separated from the people doing the work. I would first decide who is doing the work then sit with them and ask how long it would take them to complete the task. They should ask questions which may help you understand key issues that otherwise would have gone unnoticed.
Communication is the most important thing when doing project management. Treating work independent of the people doing the work is wrought with too many factors that you wind up with a bad estimate.
I wouldnt simply apply a factor based on an increase in headcount. I would imagine that your original estimate of 25 weeks was based on some breakdown of all the tasks involved in the project. When considering a second developer on the project, you should look at that task list and see where this person would be able to help. Once you have identified those tasks that he/she will work on, you can keep as accurate the original estimates on the rest. You then should estimate the amount of time this person would need, based on expertise, ramp-up time, etc, to complete the tasks you are delegating.
I would divide the estimate up into 2:
Say each dev needs 2 week start up, then your original estimate would be 2 week start up and 23 week work.
Adding a dev would then cost you an extra 2 weeks of effort on the project.
In addition you need to take into account the cost of coordination between the developer. One way to estimate this is to say that each dev needs to talk to each other dev 5 mins per day. In your case that would add an extra 10 mins of effort per day.
It is also dependent upon the possiblity of dividing up the project. Does for example your project lend itself to being divided ut into layers, one does the database, one does the UI.
The most important factor, however, is the quality of the new developer. Depending upon that you can get anything from a negative impact in productivity, that is it will take longer in calender time, to taking less than half the time.
Not only does it depend on the developer - as many stated above - it also depends on the work. Can the project be sub-divided enough, are there any external factors that will impact either developer from progressing (the ole' you can't add 2 more women to have the baby in 3 months instead of 9 months pattern). I would determine if the work can be divided effectively (decoupled areas), understand the level of the other programmer (someone new? or someone you already have in mind) and create the est. with any assumptions needed (such as 3rd party interfaces, expected changes, etc.)