I am pretty inexperienced with working in agile projects but I have tried it a few times and I always run into this problem when estimating a task.
Do we bring into the estimate the number of developers that will work on the task?
Let me explain:
Task A is estimated to one time unit and developer 1 will work on it.
Task B is also estimated to one time unit and developer 2 and 3 will work on it together.
I.e. if developer 1 begins to work on task A at the same time developer 2 and 3 begins to work on task B they will all finish at the same time according to the estimate.
Should the estimate for task B be twice of that for task A or the same?
The problem as I see it is that when a task is received and estimated, it is not always possible to know how many people will work on it. And if you assumed that two developers would work on the task for one time unit but it turns out that only one developer will actually do it, this will not automatically mean that that developer will work on it for two time units.
Is there any standard practice for this?
Best Answer
The number of developers should not be considered when estimating. However, the skill of the developer(s) should.
Initially you should be considering the complexity of the task. This is all relative, so all it tells you is that task A is twice as hard as task B, but 30% easier than task C (for example).
Then once you've got these complexity values you need to assign the man hours (or effort). This will vary depending on the skill of the developer. Task A might take 2 hours for an experienced developer, but might take a junior 8. Again, though you are ignoring how many developers are assigned to the task.
When you do assign developers you don't just simply divide the man hours by the number of people. There is an overhead - each person you add to a task reduces the overall effectiveness of the team until you get to a point where adding a person actually makes the task take longer.