Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been reading Steve McConnell's demystifying the black art of estimating book, and he gives an equation for estimating nominal schedule based on Person-months of effort:

ScheduleInMonths = 3.0 x EffortInMonths ^ (1/3)

Per the book, this is very accurate (within 25%), although the 3.0 factor above varies depending on your organization (typically between 2 and 4). It is supposedly easy to use historical projects in your organization to derive an appropriate factor for your use.

I am trying to reconcile the equation against Agile methods, using 2-6 week cycles which are often mini-projects that have a working deliverable at the end. If I have a team of 5 developers over 4 weeks (1 month), then EffortInMonths = 5 Person Months. The algorithm then outputs a schedule of 3.0 x 5^(1/3) = 5 months.

5 months is much more than 25% different than 1 month. If I lower the 3.0 factor to 0.6, then the algorthim works (outputs a schedule of approx 1 month). The lowest possible factor mentioned in the book through is 2.0.

Whats going on here? I want to trust this equation for estimating a "traditional" non-agile project, but I cannot trust it when it does not reconcile with my (agile) experience. Can someone help me understand?

share|improve this question
    
What happens if you compute ScheduleInWeeks instead of ScheduleInMonths? –  Dan Pichelman Nov 2 '12 at 14:25
    
Agile and traditional projects are different what makes you think estimations with them are the same? also assuming 5 person months of effort for 5 people over 4 weeks is fairly optimistic, you never had anything happen that took time away from at least one person (meetings, vacation, break fixes). –  Ryathal Nov 2 '12 at 14:31
1  
@DanPichelman, I got the impression that the algorithm is not the same if you change the unit of measurement. –  Steve Campbell Nov 2 '12 at 14:35
    
@Ryathal, that is true, but it is also true on a non-agile project. I suppose I could plug in the agile estimates, which are in my experience about 3x smaller, which would give me 3.0 x (0.33)^(1/3) = 2 months. The schedule is still off by 100%, although replacing the 3.0 with 1.4 works (but is still outside of the expected range of 2-4). –  Steve Campbell Nov 2 '12 at 14:39
    
What does that equation even do? Is it possible to understand it without having read the book? –  Robert Harvey Nov 2 '12 at 19:46
show 4 more comments

2 Answers

Consider two projects A and B. Project A has a certain amount of effort, and is estimated to take 1 month. Project B is estimated to have 27 times as much effort as project A. The equation appears to tell us that project B will only take 3 months.

I find this HIGHLY counterintuitive.

share|improve this answer
    
No, you have to multiply by the "factor", which varies, but is never less than 2 and should be constant for a particular development organization. So, using a factor of 4, 4 x 27^(1/3) = 12 months, i.e. you can utilize more (2.25) developers to do the work in less time than 1 would take. Its just an approximation, so you would probably say 3 developers to be safe. –  Steve Campbell Nov 5 '12 at 22:48
add comment
up vote 1 down vote accepted

I don't think there is going to be an answer to this from someone else, so I'm going to put my own answer here:

I think that @Ryanthal is right - Agile iterations just don't follow the same schedule estimating equation as waterfall projects. I suspected that when I asked the question - I just needed an explanation as to why.

The equation basically says that there is a hard-limit to how many people can work on the same thing at the same time, and the less work there is, the more difficult it is to scale the work across the team. We've all experienced this on small projects - splitting the work between 2 people is a challenge, and has some degree of inefficiency. Splitting more work between 3 people is a little more manageable, but still hard.

I think this still applies to Agile projects, but Agile projects make a concerted effort every 2-4 weeks to address this challenge by planning the way they break the work up for the iteration, with the constraint of delivering working software, and working in a collaborative environment. Doing so allows Agile more freedom to scale the team (at least within the agile sweet spot of 3-10 developers).

Its like a traditional waterfall project is a monolithic server application that can only be scaled up. You can add more memory, but then you bang up against a CPU constraint. You improve CPU, and memory or disk is the new constraint. Its just difficult to scale, and you can run up against some hard limits. Traditional projects are constrained in how effectively they can use the available developer resources, because the work is treated as one monolithic chunk.

(In terms of resourcing and schedules), Agile is more like server-component architecture where each of the pieces can be scaled individually, across multiple servers. If the authorization component is a bottleneck, spin up another instance. You can still run into hard limits, but within the capabilities of the infrastructure you have a lot of flexibility.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.