Schedule estimation and uncertainty surrounding the cone of uncertainty

Little, T.

doi:10.1109/ms.2006.82

Cited by 39 publications

(33 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In other words, as more of the project was complete, the smaller the standard deviation of responses for t total . These results confirm previous hypotheses about a software engineering phenomenon referred to as the cone of uncertainty [13,14]. Responses from the three stages have been plotted and rotated ninety degrees to the right to demonstrate the visual convergence of results.…”

Section: Discussionsupporting

confidence: 84%

Cognitive Limits of Software Cost Estimation

Begel

Nagappan

2007

First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007)

View full text Add to dashboard Cite

show abstract

Section: Discussionsupporting

confidence: 84%

Cognitive Limits of Software Cost Estimation

Begel

Nagappan

2007

First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007)

View full text Add to dashboard Cite

show abstract

“…We show this by introducing another case study from an earlier IEEE Software paper. 13 Comparing all the case studies together, we show that without taking forecasting biases into account, it's almost impossible to make any general statement about estimation accuracy across institutional boundaries.…”

Section: Meaningless Figuresmentioning

confidence: 95%

The rise and fall of the Chaos report figures

2010

View full text Add to dashboard Cite

I E E E S o f t w a r E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y0 7 4 0 -7 4 5 9 / 1 0 / $ 2 6 . 0 0 © 2 0 1 0 I E E E focus management hardly help increase project success. Over the years, their figures have attracted tremendous attention.However, we question the validity of their figures. Robert Glass 2,3 and Magne Jørgensen and his colleagues 4 indicated that the only way to assess the Chaos results' credibility is to use Standish's data and reiterate their analyses. But there's another way: obtain your own data and reproduce Standish's research to assess its validity. We applied the Standish definitions to our extensive data consisting of 5,457 forecasts of 1,211 real-world projects totaling hundreds of millions of euros. Our research shows that the Standish definitions of successful and challenged projects have four major problems: they're misleading, one-sided, pervert the estimation practice, and result in meaningless figures. Misleading DefinitionsThe Standish Group published the first Chaos report in 1994, which summarized Standish's research findings and aimed to investigate causes of software project failure and find key ways to reduce such failures. 1 The group also intended to identify the scope of software project failures by defining three project categories that we recall verbatim:■ Resolution Type 1, or project success. The project is completed on time and on budget, offering all features and functions as initially specified. ■ Resolution Type 2, or project challenged. The project is completed and operational but over budget and over the time estimate, and offers fewer features and functions than originally specified. ■ Resolution Type 3, or project impaired. The project is cancelled at some point during the development cycle. 1To find answers to their research questions, Standish sent out questionnaires. Their total sample size was 365 respondents representing 8,380 applications. On the basis of the responses, Standish published overall percentages for each project cat-F or many years, researchers and practitioners have analyzed how to successfully manage IT projects. Among them is the Standish Group, which regularly publishes its findings in its Chaos reports. In 1994, Standish reported a shocking 16 percent project success rate, another 53 percent of the projects were challenged, and 31 percent failed outright.

show abstract

“…The cone of uncertainty is a concept introduced by Boehm [8] and made prominent more recently by McConnell [24] based upon the idea that uncertainty decreases significantly as one obtains new knowledge as the project progresses [22]. Team A's estimation accuracy was relatively low starting from the first iteration.…”

Section: ) Planning Pokermentioning

confidence: 99%

Scrum + Engineering Practices: Experiences of Three Microsoft Teams

Williams

Brown

Meltzer

et al. 2011

2011 International Symposium on Empirical Software Engineering and Measurement

View full text Add to dashboard Cite

-The Scrum methodology is an agile software development process that works as a project management wrapper around existing engineering practices to iteratively and incrementally develop software. With Scrum, for a developer to receive credit for his or her work, he or she must demonstrate the new functionality provided by a feature at the end of each short iteration during an iteration review session. Such a short-term focus without the checks and balances of sound engineering practices may lead a team to neglect quality. In this paper we present the experiences of three teams at Microsoft using Scrum with an additional nine sound engineering practices. Our results indicate that these teams were able to improve quality, productivity, and estimation accuracy through the combination of Scrum and nine engineering practices.

show abstract

Schedule estimation and uncertainty surrounding the cone of uncertainty

Cited by 39 publications

References 2 publications

Cognitive Limits of Software Cost Estimation

Cognitive Limits of Software Cost Estimation

The rise and fall of the Chaos report figures

Scrum + Engineering Practices: Experiences of Three Microsoft Teams

Contact Info

Product

Resources

About