3

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?

Steve Campbell
  • 266
  • 3
  • 7
  • What happens if you compute ScheduleInWeeks instead of ScheduleInMonths? – Dan Pichelman Nov 02 '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 02 '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 02 '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 02 '12 at 14:39
  • 1
    What does that equation even do? Is it possible to understand it without having read the book? – Robert Harvey Nov 02 '12 at 19:46
  • 1
    @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. – Steve Campbell Nov 05 '12 at 15:57
  • Not that I know anything about what you're talking about, but is Basic supposed to be capitalized in this question? – Peter Turner Nov 05 '12 at 19:02
  • It seems to me that you are not interpreting the equation correctly at all. Where in the equation does it account for 5 developers? The equation works exactly correctly, 5 months of effort yields 5 months estimated effort. What else would you expect? Do you need to take the calculated value and divide by the number of people, which will of course be wrong since not all people are created equally. – Dunk Nov 05 '12 at 21:07
  • @Dunk, in the example, the agile team completes 5 person-months of work in 1 month, not the expected 5. Yes, not all people are created equally (Steve McConnell knows this - he is the one attributed to saying that some developers are 10x more productive than others), but in planning project schedules, you have to assume that they are. – Steve Campbell Nov 05 '12 at 22:56

3 Answers3

2

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.

neener neener
  • 106
  • 7
1

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.

Steve Campbell
  • 266
  • 3
  • 7
-1

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.

John R. Strohm
  • 18,043
  • 5
  • 46
  • 56
  • 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 05 '12 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. – John R. Strohm Feb 03 '16 at 14:28