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.

If you have a task that can be performed by multiple people, I would suggest that you’re estimating at too high a level. Try to break your tasks down to something approaching atomic chunks of work. In this way your question “goes away” and it becomes easier to schedule (and communicate) as work can be performed serially or in parallel depending on other priorities.

Short answer; no, I do not believe the number of developers is an input to an estimation activity. However, in constrast to the answer from @ChrisF, I also do not believe that developer skill, or any other facet of ‘complexity’ should be an input to an estimation activity.

See my (rather long) response to this question; Should you ever re-estimate user stories?, where I discuss my views on complexity and estimation.

Number of developers, developer skill, and other aspects of complexity (such as choice of language, existing code libraries available) are all factors which will contribute to how long a task takes, but they should not change the size of the task, which is what you should be aiming to measure in your estimations.

Another example (on top of the one in that other thread); you have a user story which reads something like; “I want a button, which when clicked will show an error message to unauthorised users”. Now, your team estimates this task as “small” (at least, mine would!), and it goes in your backlog. Your team of 3 developers take 1 sprint to achieve this task. Another team of 10 developers may take 2 sprints to achieve the task, because this is their first ever job, and 7 of them don’t share a common language. On the other hand, your lead developer by himself takes 1/2 a sprint to achieve this task, because he’s done it before and knows some tricks.

At the end of these 3 different periods (1, 2, 1/2 sprints) what do you have? [thinking, thinking…] Correct! A button, which when pressed shows an error message to unauthorised users. The size of this task – has not changed between these 3 teams, they’ve all produced exactly the same output. However, other factors in the development process have affected the outcome in relation to time (and probably quality, code-reuse, and other nice things).

Estimating this way feeds much more effectively into velocity measurements (team 1 has good velocity, team 2 poor, and team 3 fantastic). Now we can adjust other aspects of the development process to get better results – e.g; give team 1 a couple more developers, split team 2 into smaller teams and add some experience, give team 3 some mentoring jobs so the other teams can improve.

On the other hand, if you estimate on complexity, or team capability, you skew your velocity, and conceal where the problems lie. Imagine instead that team 1 estimated the task as “medium”, team 2 as “large” and team 3 as “small”. We assign those estimates a velocity score of 10, 20, 5 respectively (for example).

Now after 1 sprint, team 1 has achieved 10 points, team 2 has 0 points (as the task is incomplete – but they will get 20 points after 2 sprints), and team 3 has 5 points (and probably another 5 as he could fit another small task into his sprint). AS you can see from these contrived example, the velocity of all teams is going to come out much the same. We have no way to then improve velocities. If you estimate this way, all you have come out with is an abstracted estimation of time.

To complicate this approach further – what seems complex now may not be so later (after you write more framework code, developers upskill, etc), or it may become more so (framework code is hard to work with, experienced developers leave the team, etc). So you’ll need to re-estimate tasks every sprint to maintain consistency, which will mean re-estimating ALL (or many) tasks in your backlog so you can effectively prioritise them, which is all just wasted time – at the end of the activity, all teams are still producing the same button with the same warning.

So in summary, complexity, developer skill, team size, etc, should all form part of a planning activity, not a sizing activity. That way, it is clear that if you want the team to achieve more, you can adjust team metrics. You can not adjust time.

UPDATE

My response to a comment below is a bit long, so here it is in update form.

In regards to the “button” story; I just came up with some arbitrary story which could represent a single piece of work to illustrate my points. Another team might view this as a bigger task.

Estimating size of stories to a large extent depends on the Product Owner and the context of the system being developed (back-end, embedded, GUI, web, etc). I would aim to estimate the size in terms of what is being delivered, not how, or when. In the case of my example, the deliverable is a button and a dialog – ‘small’ size estiamtes to me. You could equally consider a deliverable to be a security framework, if that in itself is a deliverable for which the PO gains some perceived value (e.g; “I want single sign on support for our website so I don’t have to remember lots of passwords”).

You want to break it down into a set of steps early on. The first step is the estimation and that is estimating the cost of the task in your preferred agile units.

Your developers will be able to process a certain number of units per sprint, this varies among developers depending on their skill level. Skill level is not just technical ability, but things like familiarity with the code and business domain.

One thing I haven’t seen mentioned so far is, if you are estimating the cost of a bit of work and you think it will have multiple developers working on it, then you probably haven’t broken the story down into sufficiently small stories.

I’d suggest using some abstract values (something similar to Scrum’s story points) in order to determine how much work does it take to solve the problem. Every developer in the team should have a monthly minimum to contribute (e.g. a junior developer should provide a minimum of 20 “points” worth solutions, a senior developer should provide around 50). Knowing the total number of points the project is worth and monthly number of points your team can provide, you could estimate how long will it take to accomplish all the tasks.