Effort Estimation

Why do we makes estimates?
Is it really hard to do?
1. Let's find out!
  1. How much time will it take you to travel home from your office at 7PM, 8PM, 9PM, or 10PM?
  2. How many stands of hair do your seatmate have?
  3. How many bees does an average hive of African honeybees have
What are factors that affects estimates?
Estimates, Targets, Commitment
1. Estimates
  1. prediction of how long or how much a project will take
2. Targets
  1. statement of a desirable business objective
3. Commitment
  1. promise deliver a defined functionality at a specific level of quality at a certain date
Accuracy vs Precision
1. Precision
  1. exactness of measurement
2. Accuracy
  1. closeness to the target
Plan vs Estimates
1. Estimate
  1. unbiased analytical process
  2. goal is accuracy
2. Plan
  1. biased goal-seeking process
  2. deliberately bias plans to achieve a specific end
Count, Compute, Judge
1. Count if it is all possible.
  1. Look for something to count that is a meaningful measure of work in your environment.
2. Compute if you can't count directly.
  1. Use computation to convert a count to estimates.
  2. Collect historical data that allows you to compute an estimate from a count.
3. Use judgement alone only as a last resort.
Techniques
1. SLOC
  1. count number of lines of the delivered source code of the software, excluding comments and blank lines
  2. convert to effort estimate
  3. SLOC originated as a metric when the most commonly used languages, such as fortran and assembler, were line-oriented
    1. Programs with higher SLOC values take more time to develop
  4. Experiments have repeatedly confirmed that effort is highly correlated with SLOC
2. Function Points
  1. measurement to express the amount of business functionality an information system provides to a user
  2. count
    1. External User-input types - data or control user-input types
    2. External User-output types - output data types to the user that leaves the system
    3. External Inquiry types - interactive inputs requiring a response
    4. Internal file types - files (logical groups of info) that are used and shared inside the system
    5. External file types - files that are passed or shared between the system and other systems
  3. assign complexity
    1. 1 = simple
    2. 2 = medium
    3. 3 = complex
  4. assign weight
    1. 3 (for simple input) to 15 (for complex internal files)
  5. compute
  6. convert to effort estimate
3. Analogy/Historical Comparison
  1. compare against a similar project
4. Group Review
  1. review the requirements as a group
  2. discuss & agree on the high & low ends of the estimate
  3. arrive at a consensus estimate for the whole group
5. Wideband Delphi
  1. Delphi
    1. several experts creates independent estimates & then meets (for as long as necessary) to agree on a single estimates
    2. no more effective than a structured group meeting
    3. affected by politics & dominated by the more assertive estimators in the group
  2. anonymous individual estimates are submitted
  3. estimates compared with one another presented to estimators
  4. estimators agree to accept average estimate or to vote "no"
  5. final estimate is the range created & the single-point is the expected case
Support
1. Setting the Mindset & Expectations
  1. Cone of Uncetainty
    1. Shows how estimates becomes more accurate as project progresses.
    2. The cone helps explain why your estimate is not accurate at the beginning and when you can make it more accurate.
    3. p84
  2. Confidence Range Chart
    1. Show level of confidence that project can be completed over time spent in the project.
    2. p82
  3. How Little Can You Do
    1. How-much thinking carries these assumptions:
      1. • People are not a scarce resource. We should put all of them to use immediately, working like mad on the project.
      2. • Schedule really doesn’t matter.
      3. • Cost of development is not a driving factor.
    2. How-little thinking carries these assumptions:
      1. • Understanding the requirements is a scarce resource. We should focus our energies on delivering something that shows we understand the speciﬁc requirement and the value it has to our customer.
      2. • Schedule is critical, and we don’t have time to do it again or build technical debt.
      3. • Project cost is important, and we need to manage it.
    3. Too often, project managers (and their senior managers) say that the characteristics of how-little thinking are important, but they manage according to how-much.
    4. p93
  4. Separating Sizing & Duration
    1. Separate size & duration during estimation.
    2. Size
      1. size relative to another activity
      2. use fibonacci numbers
      3. break apart large tasks to get better sizing
    3. Duration
      1. factor in resources that will perform the task
      2. architects vs jr. programmer
    4. p86
2. Facilitating the Process
  1. Inch-Pebble
    1. one day to two days tasks that are either done or not done
  2. Rolling-Wave Schedule
    1. A rolling-wave plan is a continuous detailed schedule that’s only a few weeks long. As you complete one week of detailed schedule, you add another week to the end of the schedule.
  3. Planning Poker
    1. As a team, everyone determines the relative sizing for a feature.
    2. Use Fibonacci numbers.
3. Other Stuff that Would Help
  1. Diseconomies of Scale
    1. As project size increases, the number of communication paths increases as a squared funtion of the number of people on the projet. As a consequence, there is also an exponential increase in effort.
  2. Law of Large Numbers
    1. If you create one big estimate, the estimate's error tendency will be completely on the high side or completely on the law side. But if you create several smaller estimates, some of the estimation errors will be on the high side, and some will be on the low side. The errirs will tend to concel each other out to some degree,
  3. Student Syndrome
    1. When given time, developer will procrastinate until late in the project, at which point they'll rush to complete their work, & probably they won't finish the project on time.
  4. Parkinson's Law
    1. Work will expand to fill available time.
Overestimation vs Underestimation
1. Underestimation
  1. Management approving proposed system that exceeds budget
  2. Incomplete delivery of functions &/or with poor quality
  3. Failure to complete on time
  4. 1. Reduced effectiveness of project plan.
    2. Statistically reduced chance of on-time completion.
    3. Poor technical foundation leads to worse-than-nominal results.
    4. Destructive late-project dynamics make the whole project nominal.
      1. more meetings with upper management to get project on track
      2. frequent reestimation, late in the project, to determine when project can be completed
      3. apologizing to key customers for missing delivery dates (including meeting with those customers)
      4. preparing interim releases to support demos, trade shows, etc
      5. more discussions which requirements absolutely must be added because the project has been underway long
      6. fixing problems arising from quick & dirty workarounds that were implement in response to schedule pressure
2. Overestimation
  1. Too many resources committed to the project
  2. Not winning the contract during bidding because
  3. 1. parkinson's law kicking in
    2. attack of the goldratt's syndrome
What's the best estimation technique?
1. is what works for you according to your constraints
2. O&B's estimation process
  1. use of RFP
  2. initial requirements discussion
  3. estimation process
    1. estimation checklist
    2. group expert judgement
    3. planning poker
    4. derive expected case
      1. best case
      2. most likely case
      3. worst case
    5. impute sizing & duration requirements
Tips (Manage IT)
1. Tips to Make Estimation Easier
2. Here are approaches that will make estimation and reporting your estimates easier:
3. • Remember that an estimate is an approximation—a guess. The bigger the guess, the more error you will have. Make sure when you provide an estimation of the project completion “date,” you provide a range of dates so your audience understands that your estimate is a guess.
4. • Many software people are optimistic. They are trained to be optimistic in school, where every project can be completed in one semester (with a sufﬁcient number of all-nighters). That training will persist unless they learn to estimate small pieces and receive feedback on their estimation.
5. • Tasks will take longer than you think they will.
6. • It’s easier to estimate smaller chunks of work.
7. • Decide how everyone on the team will estimate: in person-days or hours. I recommend person-hours.
8. • You and your project team need to practice estimation and receive feedback about estimation. Estimation without feedback is write-only estimation — it makes you feel good, but it doesn’t produce long-term results and is ultimately rendered worthless.
9. • Plan to iterate on the estimates. If you realize partway through the project that your estimates are too optimistic, take the time to reestimate and replan the rest of the project. Late projects don’t make up time; they get later. Even if your project doesn’t appear to be late, take the time to reestimate.
10. • If you’ve been given a project deadline, you don’t need to estimate anything at all. Rank the features so you implement features by priority. For this case, I strongly recommend you use an agile life cycle so that you can implement and get feedback quickly. If you can’t use an agile life cycle, consider an incremental life cycle, implementing by feature as you proceed.
11. • Timebox phases and tasks if you have an overconstrained project.
12. • Consider a spike if the task is too big (too much technical risk) to estimate well.
Remember This
1. • Never provide a single-point date for an end date.
2. • The smaller the task, the easier it is to estimate.
3. • Look for estimate accuracy, not precision.
Notes
1. Remove Variability
2. Lessen Granularity