Effort vs (Size, Productivity, Duration)

Question

Well, this metric is causing some troubles in my head.

As far as I understood, its magnitude is: man/hour. So for example, if in a project I put two employees working, the effort would be: 2 man/hour. Is this ok?

Then suppose my industry is Software development, and the productivity of each man is 100 LinesOfCode/hour. Is this magnitude ok?

That means that my total productivity per hour is: Effort*IndividualProductivity = 200 LinesOfCode/hour. Is this ok?

If my project size is 1000 LinesOfCode, that means that: Duration = Size/TotalProductivity = 1000/200 = 5 hours.

I'm sorry this is not an specific question. It's more like an 'Its ok this reasoning?' one.

Answer 1

Your calculations are mathematically correct, but they assume that productivity is linear. It's not true in most cases. Especially it's not correct for writing code, which size can hardly can be measured by lines of code.

Software Lines of Code (SLoc) metric is used "post-mortem", when the product is ready and we are interested to calculate our "productivity". But it should not be used for estimating. Other metrics will help you there, like function points, story points, etc.

Answer 2

First, I'd like to point out that you are writing the metric down wrong. Man/hour implies "men per hour (men/hour)", which is essentially a rate, not an output.

When you talk about the amount of total work performed, you're not referring to rates but instead are referring to output.

A man-hour or person-hour is the amount of work performed by an average worker in one hour.

Read more: http://www.answers.com/topic/man-hour#ixzz1L4B7a4N5

When you hear someone using the term "man hours", it's actually written as "man-hours" (not man/hours) and implies that it's the total number of "men" in this case multiplied by the total number of hours in the period.

So if I have 5 developers who work 8 hours per day, then 8*5=40 man-hours of work performed in one day. Whereas a rate involves division, output involves multiplication, so the two units will appear side by side, not one over the other with a division sign.

With that said, the Wikipedia article on Man Hours goes on to say that this type of measurement of output is really only effective for measuring simple tasks with simple dependencies that are also very predictable.

For instance, in the shipping industry, it's reasonable to assume that doubling your manpower will double your output, but in a chef's kitchen, adding more chefs won't make the water boil any faster.

Likewise, software engineering is not a simple production-based field with small, simple dependencies and simple tasks. Unfortunately, each engineer will bring different skills to the table, which involve different timelines and estimates. Moreover, the same developer who takes longer than other developers on one task may smoke those same developers on another task, as it's also about specialization, to some degree.

Answer 3

Regarding your lines of code per hour, I do not find anything wrong with that parametric being used for estimating, so long as that metric was identified using industry benchmarks and / or actual data tracked within your organization. What I would change, however, is I would identify the triangular (or whatever shape) distribution in which the metric lives, i.e., I would identify the optimistic or 10th percentile metric, the pessimistic or 90th percentile, and the MODE. The same way you identified the 200/hour you can identify the min and max.

If there is sufficient actual data that went into the metric, it will be a reliable metric against which to estimate. However, you do not rely on just one method of estimation; so this is one of several methods to arrive at your estimate and targets on your new project.

Answer 4

Your arithmetic is right, but the logic behind is not. Never forget productivity is not linear, exactly like 9 women cannot give birth to a baby in one month!