2

I think it is well understood that the risk in a software engineering project increases with the size of the project, and the slope of the scale exceeds linear. As the number of features increase, not only will an estimate increase, but the margin of error in that estimate increases as well.

For this reason, Agile methodology emphasizes the need to break projects into smaller efforts that will fit into a single iteration. This offers greater project predictability (and a higher level of sanity among the dev team).

Is there a name for this principle? E.g. something like "John's law?"

Has there been any research that quantifies this principle? E.g. is the relationship between size and risk geometric or exponential?

John Wu
  • 26,032
  • 10
  • 63
  • 84
  • related: [How to explain that it's hard to estimate the time required for a bigger software project?](http://softwareengineering.stackexchange.com/questions/102856/how-to-explain-that-its-hard-to-estimate-the-time-required-for-a-bigger-softwar) – gnat Oct 28 '16 at 21:56
  • I really recommend picking up a copy of Steve McConnel's "Software Estimation: Demystifying the Black Art". It talks about this phenomenon at length. – RubberDuck Oct 29 '16 at 09:43

1 Answers1

1

Doesn't answer the question exactly, but here are some ideas that are closely related:

The Cone of Uncertainty

Link

Early in a project, specific details of the nature of the software to be built, details of specific requirements, details of the solution, project plan, staffing, and other project variables are unclear. The variability in these factors contributes variability to project estimates -- an accurate estimate of a variable phenomenon must include the variability in the phenomenon itself. As these sources of variabiility are further investigated and pinned down, the variability in the project diminishes, and so the variability in the project estimates can also diminish. This phenomenon is known as the “Cone of Uncertainty” which is illustrated in the following figure. As the figure suggests, significant narrowing of the Cone occur during the first 20-30% of the total calendar time for the project.

Cone of Uncertainty

Brook's Law

Link

Brooks' law is a claim about software project management according to which "adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. According to Brooks, there is an incremental person who, when added to a project, makes it take more, not less time.

John Wu
  • 26,032
  • 10
  • 63
  • 84
  • The cone of uncertainty (at least as presented at that site) implies you should do a detailed design as early as possible to reduce risk. Agile considers this a misconception. –  Oct 29 '16 at 07:22
  • @dan1111 the Cone of Uncertainty applies just as well to a Scrum iteration as it does to an entire waterfall project. – RubberDuck Oct 29 '16 at 09:44