slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Overview PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 22

Overview - PowerPoint PPT Presentation

  • Uploaded on

Overview. Critical concepts Value of accurate estimate Where does estimation error come from Estimation techniques Count, compute, judge Structured expert judgment Estimation by analogy Wisdom. Estimating vs planning. Estimation - an unbiased, analytical process

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Overview' - amity-riley

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • Critical concepts
    • Value of accurate estimate
    • Where does estimation error come from
  • Estimation techniques
    • Count, compute, judge
    • Structured expert judgment
    • Estimation by analogy
  • Wisdom
estimating vs planning
Estimating vs planning
  • Estimation - an unbiased, analytical process
    • The goal is accuracy; the goal is not to seek a particular result
  • Planning - a biased, goal-seeking process
    • goal of planning is to seek a particular result
  • If estimate != plan: Project has to account for that risk
value of accuracy
Value of accuracy
  • Underestimate
    • Bad stuff happens
  • Over estimate
    • Parkinson’s Law will kick in—the idea that work will expand to fill available time.
sources of errors chaotic dev process
Sources of errors: Chaotic dev process
  • Requirements that weren’t investigated very well in the first place
  • Lack of end-user involvement in requirements validation
  • Poor designs and code
  • Abandoning planning under pressure
  • Developer gold-plating
  • Lack of automated source code control
sources of err omitted activities
Sources of err: Omitted activities
  • One study found that developers tended to estimate pretty accurately the work they remembered to estimate, but they tended to overlook 20% to 30% of the necessary tasks, which led to a 20 to 30%estimation error (van Genuchten 1991).
  • Omitted work falls into three general categories:
    • missing requirements,
    • missing software-development activities
    • missing non-software-development activities.
source of err optimism
Source of err: Optimism
  • In a study of 300 software projects, Michiel van Genuchtenreported that developer estimates tended to contain an optimism factor of 20% to 30%
  • Applies to management as well (US Defense dept. study)
source of err off cut estimates
Source of err: Off cut estimates
  • Avoiding off the-cuff estimates is one of the most important points in this book.
  • Don’t give off-the-cuff estimates. Even a 15-minute estimate will be more accurate.
sources of err others
Sources of err: Others
  • Unfamiliar business area
  • Unfamiliar technology area
  • Overstated savings from new development tools or methods
  • Budgeting processes that undermine effective estimation (especially those that require final budget approval in the wide part of the Cone of Uncertainty)
estimation technique count compute judge
Estimation technique: Count, compute, judge
  • If you can count the answer directly, you should do that first.
  • If you can’t count the answer directly, you should count something else and then compute the answer by using some sort of calibration data.
what to count
What to count
  • Early in the development life cycle, you can count marketing requirements, features, use cases, and stories, among other things.
  • In the middle of the project, you can count at a finer level of granularity—engineering requirements, Function Points, change requests, Web pages, reports, dialog boxes, screens, and database tables, just to name a few.
  • Late in the project, you can count at an even finer level of detail—code already written, defects reported, classes, and tasks
counting tips
Counting Tips
  • Find something to count that’s available sooner rather than later in the development cycle
  • Find something you can count with minimal effort
  • Don’t discount the power of simple, coarse estimation models such as average effort per defect, average effort per Web page, average effort per story, and average effort per use case.
estimation technique 2 structured expert judgment
Estimation technique 2:Structured expert judgment
  • By far the most common estimation approach used in practice
  • To create the task-level estimates, have the people who will actually do the work create the estimates.
work breakdown
Work breakdown
  • Is the estimate broken down into enough detail to expose hidden work?
  • Decompose estimates into tasks that will require no more than about 2 days of effort
  • Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree.
best case vs worst case
Best case vs Worst case

Is the Worst Case really the worst case?

Does it need to be made even worse?

expressing uncertainty
Expressing uncertainty
  • The key issue in estimate presentation is documenting the estimate’s uncertainty in a way that communicates the uncertainty clearly and that also maximizes the chances that the estimate will be used constructively and appropriately