DilbertScott Adams

DilbertScott Adams

DilbertScott Adams

Special Issues in Estimating ScheduleChapter 20Estimation pressure from deadlines:• Customer• Trade show• Seasonal sales-cycle• RegulatoryOther calendar-oriented deadlines

Schedule estimates produce the most “heat” in estimation discussion

Basic Schedule EquationSchedule_In_Months = 3.0 StaffMonths⅓

One of the most replicated results in SWETip #98 Used to estimate schedule early in medium-to-large projects

• Effort increases in proportion to scope• Schedule increases in proportion to the cube root of effort

Assumes team size can be adjusted to the size implied by the equationNot intended for estimating small projects (when you know the names of those working on the project)

Computing SchedulePast Projects formula

Estmated_Schedule = Past_Schedule (Estimated_Effort / Past_Effort) ⅓

Informal Comparison to Past Projects:Medium-to-large projects (more than 50 staff month)Smaller projects use ½

Schedule Effort Productivity(Calendar (Staff (LOC/Staff

Project Size (LOC) Days) Months) Month) CommentsA 33,842 8.2 21 1,612B 97,614 12.5 99 986C 7,444 4.7 2 3,722 Not used - too small for comparisonD 54,322 11.3 40 1,358E 340,343 24 533 639 Not used - too large for comparison

Chapter 19 Effort EstimateFigure 19-2 (page 209)

65 to 100 staff months, most likely 80 staff months

Past Schedule 8.2 8.2 8.2Estimated Effort 65 80 100

Past Effort 21 21 21

Estimated Schedule 12.0 12.8 13.8

Past Past Low Nominal HighSchedule Effort Estimate Estimate Estimate(Calendar (Staff (65 Staff (80 Staff (100 Staff

Project Days) Months) Months) Months) Months)A 8.2 21 12.0 12.8 13.8B 12.5 99 10.8 11.6 12.5D 11.3 40 13.2 14.2 15.3

Averages: 12.0 12.9 13.9

Estmated_Schedule = Past_Schedule (Estimated_Effort / Past_Effort) ⅓

Computing Schedules from FPLow-accuracy (low effort) schedule estimate

• Capers Jones, based on 1,000 of projects• Using the Better / Average / Worse exponents below• Example

Project estimate: 1,450 FPsBusiness system (average productivity)

Estmated_Schedule = 1,450 0.39 ≈ 17 calendar months

Kind of Sfotware Better Average WorseObject Oriented 0.33 0.36 0.39Clent server 0.34 0.37 0.40Business systems, internal intranet systems 0.36 0.39 0.42Shrink-wrapped, scientific systems, 0.37 0.40 0.43

engineering systems, public intenet systesmEmbedded systems, telecommunications, 0.38 0.41 0.44

device drivers, systems SW

Using the Science of EstimationConstrux Estimate

• The “art of estimation” fails… schedules vary too much and depend on many factors

• Construx estimate:Schedule = 12.2 calendar months(with 20% to 80% range of 11.6 to 12.9 months)Using industry average data schedule = 15.8 months(with range of 13.2 to 21.5 months)

www.construx.com/estimate

Adjusting the nominal schedule

• Depends on whether features can be cut (to get less work in less time)

• If feature set cannot be cut, you need more staff to do more work in less time

• What have researchers found?There is a maximum degree to which a schedule can be compressedShortening means increasing effort

12 months with 7 = 7 months with 12

Schedule Compressionand

Shortest Possible Schedule

Compression requires more effortReasons:• The larger the team, the more coordination & management• The larger the team, the communication needs increase• Shorter schedules require more work done in parallel

The more work that overlaps, the greater the chance that there will be integration problems… requiring rework

Tip #92Do not shorten a schedule estimate without increasing the effort estimate.

The Impossible ZoneThe LogicEstimate: 8 people needed for a 10 month projectDoes not mean:

80 people can complete the project in 1 month1,600 people can complete the project in 1 day

ConclusionThere is an Impossible Zone

A point beyond which schedule compression cannot happen

Tip #9325% compression is the limit… to keep out of the Impossible Zone

Extending the project schedule

• Reduces total effort (by reducing team size), usually• The negatives associated with compression become

positives with extending the project• General rule (and answer to the question in Ch. 3.1)

“It is better to overestimate that underestimate”

Effort and Schedule TradeoffsRules of Thumb (Lawrence Putnam)(for schedule compression and expansion)

Schedule Compresson/

ExpansionEffort Increase/

Reduction-15% 100%-10% 50%-5% 25%

Nominal 0%10% -30%20% -50%30% -65%

More than +30% Not practical

Schedule Compression & Team SizeAgain, Putnam’s research (see bottom, page 229)

Tip #95Med. business systems projects (35,000 to 100,000 LOC) avoid increasing Team size above 7.

Comparison of Different Months• Estimates vary (no apparent convergence)• Basic Schedule coefficients (2.0 to 4.0)

Comparison of Different Methods• Use historic data… adjusting to a range of 2.7 to 3.7

Narrows schedule range to 11.6 to 14.1 monthsConvergence is apparent

Tip #97Remove results of overly generic estimation techniques before looking for convergence.