Team productivity vs team size

Question

I am looking for information about how the team size impacts project velocity. Let's assume that I have a small project estimated at 300 hours for single worker. What impact does team size have on estimation? Is there any publications/book describing this relationship?

I mean something like this:

• 1 person team - 300 h
• 2 person team - 300 h + n%
• 3 person team - 300 h + m%

During my work, I've noticed that project velocity depends on team size. I want to know the scale factor in order to better estimate projects.

Answer 1

Are the workers of same skill? Do they use same tools? Can they work in tandem? Is the work allocated to them of similar complexity? Is the work environment same for all workers?

If answer to the above questions is yes, then you can say that velocity is directly proportionate to the team size.

If answer is no then its almost impossible to find out scale factor..

The thing with estimates is that it cannot be exact, exact estimate is oxymoron.

You can mention in the estimates you give that for a given task of 300 person hrs if we have 2 workers with similar skills we can complete it in 150 calendar hours.

Estimates should always be accompanied with assumptions (in this case similarly skilled workers)

Answer 2

I believe, there are no formulas for calculating "scale factor". There are too many factors, that may affect this parameter. Such as:

• Can work be done in parallel?
• Complexity of whole project.
• Communication ability of team members.
• Organization of your working process (take a look at this question: Number of communication channels in Chief-Programmer model).
• Etc.

So, I think, you could estimate this parameter only in empirical way.

Answer 3

Honestly, as a technical lead of many teams, I will say if anyone had a formula for determining velocity, I would deem it ignorant at best, and out-right harmful at worst.

Velocity is descriptive, not prescriptive.

It is our jobs as leaders to use the data that is flowing in to forecast the future, but by no means could anyone say for an absolute certainty what the impact of building out a team is because of the infinite number of variables.

With that being said, I have had to do this to communicate estimated timeframes for executives. I make sure to put in disclaimers, but I use a high level 18 points for seniors, 12 for intermediate and 8 for juniors as my base-line expectations for a normal web-based CRUD app. Every new person impacts the tech lead, so I take off of their time first. Probably, depending on the organizational design of the team...maybe 10% per junior, and 5% for intermediate or senior. As for the rest of the team, it is too hard to say, so I'd probably just have it impact the tech lead to start off with.

Answer 4

I read a book about 10 years ago that discusses this beautifully by Fred Brooks. The Mythical Man Month: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

His constant argument is adding people increases the time to deliver. I believe he settled on a team of about 7 - from memory he is considering large scale projects, each person tends to have defined functions, these aren't all developers!

I think Google settled on 3 for things too (I guess that's when staff ideas get promoted into a lab). Certainly, a team of two or three is far more cohesive and effective with the result!

Answer 5

McConnell in his "Software Estimation" book Chapter 20 saying that scale factor dramatically impacts total project cost: "If you try to shorten timeline just -15% from nominal, then it increases cost 100%. If you increase timeline +30% from nominal, then it decreases cost -65%."

So, obviously we should include some additional costs, because of bigger team. But McConnell doesn't provide easy way to calculate the "nominal" size of the team to be able to use numbers % above in any kind of estimating formulas...

Answer 6

Like everyone said, there's no magical number, it all depends on your particular situation. At best, for each individual, it'll add a little overhead in administration, at worst, you'll find yourself rewriting completely the plan so it is suitable for multiple individuals (and cof cof, 10-20% of the time is arguably dedicated to planning...).