INTRODUCTION TO

ESTIMATION FOR QC

October 2015
Agenda

 What is Estimation?
 Classic Mistakes in Software Estimation.
Cone of Uncertainty
 Estimating Techniques
 Estimation Dos and Don’ts
 Practical Pieces of Advice

2
WHAT IS ESTIMATION?
What is Estimation?
Estimate – an approximate calculation or judgment
of the value, number, quantity, or extent of something

“an estimate “a rough idea

of what it how long it
would cost” would take”

US Headquarters – Fort Myers, FL

Estimates vs Targets vs Commitments
"We need to have
Version 2.1 ready to
demonstrate at a trade
show in May"
“The Version 2.1 will
be ready till the May"

Do not confuse
Why do we need an estimate?

Estimates form the foundation

for the plans
Why do we need an estimate?

Useful
Perfectly accurate estimate
Why do we need an estimate?

A good estimate is an estimate that provides a

clear enough view of the project reality to allow
the project leadership to make good decisions
about how to control the project to hit its targets
Overestimate vs Underestimate

9
Benefits of good estimates

 Improved status visibility

 Higher quality

 Better budgeting

 Early risk information

 CLASSIC MISTAKES IN
SOFTWARE ESTIMATION.
CONE OF UNCERTAINTY
Classic Mistakes in Software Estimation

1. Chaotic development process

2. Errors that arise from the estimation practices:

 Omitted activities
 Unfounded Optimism
 Subjectivity and Bias
 Off-The-Cuff Estimates

3. Uncertainty… Even in well-run projects

Cone of Uncertainty
 Narrowing the Cone of Uncertainty
Don't assume that the Cone of Uncertainty will narrow itself

Force the Cone to narrow by removing sources of variability

from your project
ESTIMATION TECHNIQUES
Estimation Techniques

 Expert Judgement
 % of Dev Estimates
 PERT Estimation
 Work Decomposition
 Structured Expert Judgement
 Story Points. Planning Poker
Expert Judgment

17
%-of-Development Approach

QC Effort = Flat_Rate*(DEV Effort)

Flat_Rate є[0.3; 0.5]

Program Evaluation and Review Technique (PERT)

1. Create Worst Case (Pessimistic) estimate

2. Create Best Case (Optimistic) estimate
3. Create Most Likely Case estimate
4. Use formula to calculate the Expected Case
estimate
ExpectedCase = (BestCase + 4*MostLikelyCase +WorstCase)/6
Optimistic= 3
Most Likely = 5
Pessimistic= 10

By using the formula, this becomes

E = (3 + (4 x 5) + 10) / 6
E = (3 + 20 + 10) / 6
E = 33 / 6
E = 5.5
Work Decomposition

1. Decompose the work into very small work

packages
2. Estimate all small activities
3. Add up separate estimates

Bottom-up
Structured Expert Judgment
1. Involve experts
2. Break the big task down
3. Use Range: Worst Case (Pessimistic) and Best
Case (Optimistic)
4. Use Formulas:
ExpectedCase =
=(BestCase + 4*MostLikelyCase +WorstCase)/6
5. Use Estimation Checklists
6. Improve your estimates

21
Story Points Estimation
Story Point Estimation

23
 Story Points Estimation
 Walk through the requirements of the story

 Discuss and jot down any details you want to remember

when implementing this story

 Clarify if anything might impact the story

- Is any special setup required
- Any external dependencies
- Does anyone have prior experience?

 Size the story

Planning Poker
Planning Poker
 Those who actually could do the work are the
ones that vote

 Managers don’t vote

 When there is a tie in the voting between two

sizes which are consecutive, just pick the larger
size and move on

 Stop implementation discussions before they go

too deep. 
ESTIMATION DOS AND
DON’TS
General Flow of Estimation Process

• Analyze the Estimation basis

(system/feature/task)

• Register the factors that might influence an

estimate

• Apply Estimation techniques

• Evaluate Estimation accuracy

28
Dos

 Keep in mind the estimation purpose:

 First approach
 Proposal
 Detailed plan
 Use more than one estimation technique
 Include risk impact
 Be as accurate as possible
 Document all results
 The 'best approach' is highly dependent on the particular
organization, project and the experience of the personnel
Aspects for Consideration
 Skills
 Level of formality for Documentation
 Level of formality for Testing process
 Environment Configuration
 Test Data preparation
 Metrics collection
 Meetings/reporting/etc.
Aspects for Consideration
 Time for any possible risks
 Time for defects analysis and registration
 Time needed for retesting after defects were
fixed
 Time needed for regression testing
 Re-running regression test cases
 Time needed for automating of test cases and
their maintenance
Don’ts

 Do not confuse estimates with targets

 Do not say “Yes” when really meaning “No”
 Do not commit too early with lots of
uncertainties
 Do not assume underestimation has no impact on
project result
 Do not estimate in the “impossible zone“(compressed
schedule with a zero chance of success)
 Do not overestimate savings from new tools or methods
(Payoff is less than expected)
PRACTICAL PIECES OF ADVICE

33
QC Tasks breakdown

1. Test planning
2. Requirements Analysis
3. Test Design
4. Test Case Implementation
5. Test Execution
6. Test Status Reporting
7. Closure Activities
Requirements Analysis
 Compute the time needed to read one page from
the Requirements Specification document
 Add time for discrepancies recording

 Add time for discrepancies clarification

 Add time for requirements updating (if needed)

 Multiply the time to number of pages

 Add time for possible risks

Test Case Design and Implementation
 Calculate approximate number of
features/functional areas to be tested
 Do not forget about different test case types
(positive, negative and boundary)
 Take into account level of details for test cases
which plan to be created
 Compute time for creation of one test case
 Add time for test data preparation
 Multiply the time to approximate # of functional
areas and # of test case types + risks
Test Case Execution
 Compute time for environment preparation and/or
verification
 Consider quantity of test configurations
 Calculate time for one test case execution
 Multiply it to number of test cases and add time for
risks
 Plan time to run not only Functional testing, but
Non-Functional as well
 Consider time for Defects registration
 Consider time for Confirmation testing
 Consider time for Regression testing
Questions

Copyright © 2014 SoftServe, Inc.

 Thank you

US OFFICES EUROPE OFFICES EMAIL USA TELEPHONE

Austin, TX United Kingdom [email protected] Toll-Free: 866.687.3588
Fort Myers, FL Germany   Office: 239.690.3111
Boston, MA The Netherlands WEBSITE:
Newport Beach, CA Ukraine www.softserveinc.com UK TELEPHONE
Salt Lake City, UT Bulgaria Tel: 0207.544.8414

GERMAN TELEPHONE
Tel: 0692.602.5857