# Should the number of developers be considered when estimating a task?

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?

-
Not going to post an answer, since there are some really good ones already, but I can recommend reading up on relative estimates instead of estimating time. Also check Mike Cohn's book Agile Estimating and Planning amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415. – Qw4z1 Nov 19 '12 at 3:49

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.

-
+1, sounds like you've been there and done that. – NoChance Nov 7 '12 at 10:31
(+1 mythical man month). But it's a little more complex than your example. Some tasks just take longer than others, even though they're simpler. Refactoring a project to the proper naming convention, for example. Dirt simple, but it's going to take the skilled developer just as long as the novice. The time required for a complex task like say "This polymorphic code is going all wonky, fix it" will be directly proportional to skill/experience/having de-wonked the routine before. – Philip Nov 7 '12 at 16:55
@Philip - refactoring is a complex task not a simple one. There are two many knock on effects. It will probably take the experienced developer less time because he's aware of these issues and can be proactive in dealing with them rather than reactive like the less experienced developer would be. – ChrisF Nov 7 '12 at 16:58
But refactoring some code so it matches a naming convention is not. I know, I know, refactoring can be a major task and it can be really useful in the long run, I was just looking for simple example. Changing `do_the_function` to `doTheFunction` throughout the code just takes time. – Philip Nov 7 '12 at 17:01
@Dainius - it is not realistic to have every developer on a team at the same level. Just because one member is significantly better than the others, the team should be fired or stop being agile? – JeffO Nov 8 '12 at 14:07

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.

-
I disagree with this - at a sizing level, a story/task can be described quite simply - e.g; I want a button on a screen to buy 1 unit of the currently selected product - the PO sees this as quite a trivial story, that can't sensibly be broken down any further, but there is an implicit development requirement to build things like screens, web services, service channels, payment processing gateways etc. It is likely that several of these components can be developed in parallel by different people. Or, it may be that they have already been built. Neither scenario affects the size of the task. – RJ Lohan Nov 8 '12 at 2:23
If to estimate the task you know that it needs updates to the web services, payment processor, etc, and you know how long those tasks will take, then you're already doing what I've suggested. All I'm saying is that you write it down. If you want to summarise it down to story level, that's fine too. As you say, it doesn't affect the final number. – Stephen Darlington Nov 8 '12 at 6:54

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.

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 make some interesting points in this answer and in the one linked. Especially about increasing velocity over sprints. However I do have some questions. Why is the story of the button which shows a message to unauthorized users a small one? If we have an authorization framework running then the task does indeed seem small. But if not then the task is bigger. If we take "complexity" out of the equation then what is the basis of determening size? You make a good point about the need to re-estimate when the codbase grows but with your approach I am not sure how to estimate at all. – Ludwig Magnusson Nov 9 '12 at 11:13
@LudwigMagnusson; I've responsed to your questions inline, as it was a bit cumbersome for a comment. :-) – RJ Lohan Nov 10 '12 at 6:53

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.

-
When I say multiple developers working on the same task I mean things like pair programming, team discussions on new data models toghether etc. I have found that there are some tasks that really should be done together with others to produce the best output. – Ludwig Magnusson Nov 7 '12 at 12:54
@LudwigMagnusson if pair programming is your concern, that is a case of two developers acting as one, its not really multiple developers working on the same task – Ryathal Nov 7 '12 at 14:17
Yes, this is the thing, pair programming is a bit of a special case, but team discussions and so on fall outside of the task planning altogether. So how do you account for it? Well, your resources are depleted by the amount that would be used to hold the meeting. For simplicity, say you have 10 tasks which will each take 1 day and two developers for a 5 day sprint. Great, perfect. But both developers are out for a day doing team building in the jungle, so you still have 10 tasks that will take 1 day each, but now only 8 developer days (2 * 4), so you have to decide which 2 tasks to drop. – Ian Nov 7 '12 at 14:27
Much of what you say makes sense but HOW is the special case of pair programming handeled? Pair programming is suitable for some tasks and less for others. If my team uses both pair programming and single programming, how do we do the estimation? If task A requires one calendar day of single programming and task B requires one calendar day of pair programming, is the solution simply to estimate task A to 1 day and task B to 2 days? – Ludwig Magnusson Nov 7 '12 at 15:22
And please remember, this is how "we" work out these things. The goal is to find a system where your team are accurately predicting how long a bit of work will take and how many stories can be complete in a sprint. So what works for me may be either too complicated or too convoluted for you. That's a really important point. There's no real right or wrong unless it's right for you. – Ian Nov 7 '12 at 16:09

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.

-