Can I trust the Basic Schedule Equation?

I've been reading Steve McConnell's Software Estimation: Demystifying the Black Art book, and he gives an equation for estimating nominal schedule based on Person-months of effort:

`ScheduleInMonths = 3.0 x EffortInMonths1/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 51/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?

• What happens if you compute ScheduleInWeeks instead of ScheduleInMonths? Commented Nov 2, 2012 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). Commented Nov 2, 2012 at 14:31
• @DanPichelman, I got the impression that the algorithm is not the same if you change the unit of measurement. Commented Nov 2, 2012 at 14:35
• What does that equation even do? Is it possible to understand it without having read the book? Commented Nov 2, 2012 at 19:46
• @RobertHarvey The equation is based on multiple studies of real-world software projects. The observed phenomena is that (on waterfall projects with "completed" requirements) achievable development schedule is proportional to the cubed root of effort, when both are expressed in months. In the book, it is recommended to use as a "sanity check" for the schedule. Commented Nov 5, 2012 at 15:57

You are using the equation for something it was never intended for. Here are some of the limitations of the Basic Schedule Equation that are talked about in Steve's book:

The schedule equation implicitly assumes that you're able to adjust the team size to suit the size implied by the equation.

If your team size is fixed, the schedule won't vary in proportion to the cube root of the scope; it will vary more widely based on your team-size constraints. Section 20.7, "Schedule Estimation and Staffing Constraints," will discuss this issue in more detail.

The Basic Schedule Equation is also not intended for estimation of small projects or late phases of larger projects.

You should switch to some other technique when you know the names of the specific people working on the project.

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.

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.

• 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. Commented Nov 5, 2012 at 22:48
• @SteveCampbell, the equation as written claims that schedule rises as the cube root of effort involved. That's what I was trying to say sounded highly dubious. Commented Feb 3, 2016 at 14:28