September 2nd, 2014
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
Combining Independent Estimates Improves Estimation Accuracy
The average of effort estimates from different sources is likely to be more accurate than most individual effort estimates. A key assumption for accuracy improvement is that the estimates are independent, which is true if their sources differ in expertise, background, and estimation process. A Delphi-like estimation process, such as “Planning Poker,” where software developers show their independently derived estimates (their “poker” cards) at the same time, seems to be particularly useful in software effort- estimation contexts.
A group-based, structured estimation process adds value to a mechanical combination of estimates because sharing the knowledge increase the total amount of knowledge, such as the total amount of activities to be completed on a project. The negative effect of groupbased judgments, such as “groupthink” and the willingness to take higher risks in groups, isn’t documented to be present in software effort estimation.
Estimation models seem to be, on average, less accurate than expert estimates. The difference between the processes of models and experts make it nevertheless particularly useful to combine these two methods to
improve the estimation accuracy.
Estimates Can Be Harmful
Estimates not only forecast the future but also frequently affect it. Too – low estimates can lead to lower quality, possible rework in later phases, and higher risks of project failure; too-high estimates can reduce productivity in accordance with Parkinson’s law, which states that work expands to fi ll the time available for its completion.
This is why it’s important to consider whether an effort estimate is really needed. If you don’t really need estimates or just need them at a later stage, it might be safer to go without them or postpone the estimation until more information is available. Agile software development – which involves planning just the next sprint or release by using feedback from previous sprints or releases – might be a good way to avoid the potential harm from estimating too early.
What We Don’t Know
There are several estimation challenges for which we simply have no good solution, sometimes in spite of volumes of research. Three challenges in particular highlight how our knowledge is far from satisfactory.
How to Accurately Estimate the Effort of Mega – large, Complicated Software Projects
Mega – projects impose extra demand on effort estimation. Not only are more values at stake, but there will also be less relevant experience and historical data available. Many of the activities typical for mega – projects, such as organizational issues with many stakeholders involved, seem to be very hard to estimate accurately because they typically involve business process changes, and complex interactions between stakeholders and with existing software applications.
How to Measure Software Size and Complexity for Accurate Estimation
In spite of the years of research into measuring software size and complexity, none of the proposed measures are very good when it comes to estimating software development effort. Some size and complexity contexts might enable accurate effort estimates, but such contexts seem to be rare.
How to Measure and Predict Productivity
Even if you have good measures of software size and complexity, you need to reliably predict the productivity of the individuals or teams completing the work. This prediction is complicated by an often surprisingly large difference in productivity among software developers and teams. No good method, except perhaps realistic programming tests (trialsourcing), for this type of prediction exists.
Currently, we don’t even know whether there’s an economy of scale (productivity increases with increasing project size) or a diseconomy of scale (productivity decreases with increasing project size) in software projects. Most empirical studies suggest that software projects on average have an economy of scale, whereas software practitioners typically believe in a diseconomy of scale. Unfortunately, the research results on scale economies seem to be a consequence of how the analysis is conducted and don’t tell much about the underlying relationship between size and productivity.