Presentation made by Steve McConnell's book for my students (UX Architecture course)

1. ESTIMATIONS:
Tips & Techniques
HIT THE TARGET

2. Definition of “Estimate”
1. A tentative evaluation or rough calculation.
2. A preliminary calculation of the cost of a project.
3. A judgment based upon one’s impressions; opinion.
The American Heritage Dictionary

3. Good estimates
are within
25% of the actual results
75% of the time

4. Have you ever heard...
“We need to have product ready to demonstrate at a trade show
in May.”
“These functions need to be completed by July 1 so that we’ll be
in compliance with government regulations.”
“We must limit the cost of the next release to $20K, because
that’s the maximum budget we have for that release.”

5. Probability Statements
Single-point estimates
assume 100% probability
of the actual outcome
equaling the planned
outcome.
This isn’t realistic.

6. Probability Statements
This assumption is
incorrect because there
are limits to how
efficiently a project team
can complete any given
amount of work.

7. Probability Statements
An accurate depiction of
possible software project
outcomes. There is a limit
to how well a project can
go but no limit to how
many problems can occur.

8. Real Purpose
The primary purpose of software estimation is not to predict a project’s
outcome; it is to determine whether a project’s targets are realistic
enough to allow the project to be controlled to meet them.
Estimates don’t need to be perfectly accurate as much as they need to
be useful.

9. Planning considerations
● Creating a detailed schedule
● Identifying a project’s critical path
● Creating a complete work breakdown structure
● Prioritizing functionality for delivery
to have accurate estimation

10. Estimation improvements
Improvement in estimation
at the Boeing Company.

11. Underestimating treats
● Reduced effectiveness of project plans.
● Statistically reduced chance of on-time completion.
● Destructive late-project dynamics make the project worse than
nominal.
● Poor technical foundation leads to worse-than-nominal results.

12. Benefits of accuracy
● Improved status visibility.
● Higher quality.
● Better coordination with nonsoftware functions.
● Increased credibility for the development team.

13. Cone of uncertainty
The Cone of Uncertainty based on
common project milestones

14. It will not narrow itself
If a project is not well controlled or
well estimated, you can end up
with a Cloud of Uncertainty

15. What do we usually miss
Ramp-up time for new team
members
Mentoring of new team members
Management
coordination/manager meetings
Installation
Requirements clarifications
Participation in technical reviews
Processing change requests
Attendance at change-control/triage
meetings

16. Don’t reduce developer
estimates — they’re
probably too optimistic
already.

17. Off-the-Cuff Estimates
Average error from off-the-cuff
estimates vs reviewed estimates.

18. Proper technique
When choosing estimation techniques,
consider what you want to estimate, the
size of the project, the development stage,
the project’s development style, and what
accuracy you need.

19. Count,
Compute,
Judge

20. 1. Count, Compute, Judge
● Find something to count that’s highly correlated with the size of
the software you’re estimating.
● Find something to count that’s available sooner rather than later
in the development cycle.
● Find something to count that will produce a statistically
meaningful average.

21. 1. Count, Compute, Judge
Quantity to Count Historical Data Needed to Convert the Count to an Estimate
Marketing requirements
● Average effort hours per requirement for development
● Average effort hours per requirement for independent
testing
● Average effort hours per requirement for
documentation
● Average effort hours per requirement to create
engineering requirements from marketing
requirements

22. 1. Count, Compute, Judge

23. Calibration
on Historical
Data

24. 2. Calibration on Historical Data
If you’re not already collecting historical data, you can start with a
very small set of data:
● Size (lines of code or something else you can count after the
software has been released)
● Effort (staff months)
● Time (calendar months)

25. 2. Calibration on Historical Data

26. Individual
Expert
Judgement

27. 3. Individual Expert Judgement
When estimating at the task level, decompose estimates into
tasks that will require no more than about 2 days of effort.
Tasks larger than that will contain too many places that unexpected
work can hide. Ending up with estimates that are at the 1/4 day,
1/2 day, or full day of granularity is appropriate.

28. 3. Individual Expert Judgement

29. 3. Individual Expert Judgement
Equation #1.
Program Evaluation and Review Technique (PERT) Formula

30. 3. Individual Expert Judgement
Equation #2.
Pessimistic PERT Formula

31. 3. Individual Expert Judgement
Is what’s being estimated clearly
defined?
Does the estimate include all the
kinds of work needed to complete
the task?
Does the estimate include all the
functionality areas needed to
complete the task?
Checklist
Is the estimate broken down into
enough detail to expose hidden work?
Did you look at documented facts
(written notes) from past work rather
than estimating purely from memory?
Is the estimate approved by the person
who will actually do the work?
To be continued...

32. 3. Individual Expert Judgement
Is the productivity assumed in the
estimate similar to what has been
achieved on similar assignments?
Does the estimate include a Best
Case, Worst Case, and Most Likely
Case?
Is the Worst Case really the worst
case? Does it need to be made even
worse?
Checklist
Is the Expected Case computed
appropriately from the other cases?
Have the assumptions in the
estimate been documented?
Has the situation changed since the
estimate was prepared?

33. 3. Individual Expert Judgement
Equation #3.
Magnitude of Relative Error (MRE) Formula

34. 3. Individual Expert Judgement

35. Estimation
by Analogy

36. 4. Estimation by Analogy
1. Get detailed size, effort, and cost results for a similar previous project.
2. Compare the size of the new project piece-by-piece to the old project.
3. Build up the estimate for the new project’s size as a percentage of the
old project’s size.
4. Create an effort estimate based on the size of the new project compared
to the size of the previous project.

37. 4. Estimation by Analogy

38. Proxy
Based
Estimation

39. 5. Proxy based Estimation
Fuzzy Logic
Estimators are usually capable of classifying features as Very Small,
Small, Medium, Large, and Very Large.
We can then use historical data about how many lines of code the
average Very Small feature requires, how many lines of code the
average Small feature requires, and so on to compute the total lines
of code.

40. 5. Proxy based Estimation
Standard Components
If you develop many programs that are architecturally similar to
each other, you can use the standard components approach to
estimate size. You first need to find relevant elements to count in
your previous systems.
The specifics will vary depending on the kind of work you do. Typical
systems might include dynamic Web pages, static Web pages, files,
database tables, business rules, graphics, screens, dialogs, reports,
and so on.

41. 5. Proxy based Estimation
Story Points
When using story points, the team reviews the list of stories (or
requirements or features) it is considering building and assigns a
size to each story.
In this sense, story points are similar to fuzzy logic, except that the
stories are normally assigned a numeric value from one of the scales

42. 5. Proxy based Estimation
T-Shirt
In this approach, the developers classify each
feature’s size relative to other features as
Small, Medium, Large, or Extra Large.
In parallel, the customer, marketing, sales, or
other nontechnical stakeholders classify each
feature’s business value on the same scale.
These two sets of entries are then combined

43. 5. Proxy based Estimation

44. Expert
Judgment
in Groups

45. 6. Expert Judgment in Groups

46. 6. Expert Judgment in Groups

47. THANK YOU!
Alex Tymokhovskyi
Linkedin