17
Software Estimation Demystifying the “Black Art” … a summary, some tips & tricks to remember, after reading a book called… PART 2 of 2

Software Estimation - part 2 of 2

Embed Size (px)

DESCRIPTION

A summary, some tips & tricks, after reading a book called "Software Estimation - Demystifying the “Black Art". Should be useful for anyone who has to perform any kind of estimates, but especially useful for software developers & managers.

Citation preview

Page 1: Software Estimation - part 2 of 2

Software EstimationDemystifying the “Black Art”

… a summary, some tips & tricks to remember, after reading a book called…

PART 2 of 2

Page 2: Software Estimation - part 2 of 2

Software Estimation

PART 1 of 2 What is an Estimate? What is a Good Estimate? Estimation Accuracy

PART 2 of 2 Estimation Techniques How to Present Estimates How to Debate & Negotiate based on

Estimates

Page 3: Software Estimation - part 2 of 2

Estimation, Approximation, Guesstimation

Approximation: inexact representation of something that is still close enough to be useful.

Estimation: calculated approximation of a result usable even if input data may be incomplete or uncertain educated guess typically means finding upper and/or lower bounds of a

quantity that cannot be computed precisely

Guesstimate: an estimate that combines reasoning with guessing

Page 4: Software Estimation - part 2 of 2

Estimation Techniques

Count, Compute, Judge If you can count the answer directly, do that first. If you can't count the answer directly, count

something meaningful and then compute the answer by using some sort of calibration data.

Use judgement only for the items that cannot be counted / computed, but in conjunction with ones that can.

Count if at all possible. Compute when you can't count. Use judgment alone only as a last resort.

Page 5: Software Estimation - part 2 of 2

Estimation Techniques

Historical Data, Calibration

Use historical data as basis for productivity assumptions and to avoid politically charged discussions

Collect a project's historical data as soon as possible

Use data from your current project to create highly accurate estimates for the remainder of the project.

Page 6: Software Estimation - part 2 of 2

Estimation Techniques

Compare Estimates to Actuals Compute the Magnitude of Relative Error

(MRE) of your estimates:

Compare actual performance to estimated performance so that you can improve your individual estimates over time

Beware not to use the historical estimate – always use the historical actual

𝑀𝑅𝐸=𝐴𝑏𝑠𝑜𝑙𝑢𝑡𝑒𝑉𝑎𝑙𝑢𝑒𝑜𝑓𝐴𝑐𝑡𝑢𝑎𝑙𝑅𝑒𝑠𝑢𝑙𝑡−𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑒𝑑𝑅𝑒𝑠𝑢𝑙𝑡

𝐴𝑐𝑡𝑢𝑎𝑙 𝑅𝑒𝑠𝑢𝑙𝑡

Page 7: Software Estimation - part 2 of 2

Estimation Techniques

Structured Expert Judgment Task-level estimates – the people who will

actually do the work should create the estimates.

Use an estimation checklist to improve estimates.

Create both Best Case and Worst Case estimates (stimulate full range of possible outcomes).

Program Evaluation and Review Technique – PERT a.k.a. 3 point Estimate

𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑𝐶𝑎𝑠𝑒=𝐵𝑒𝑠𝑡𝐶𝑎𝑠𝑒+4  x𝑀𝑜𝑠𝑡 𝐿𝑖𝑘𝑒𝑙𝑦𝐶𝑎𝑠𝑒+𝑊𝑜𝑟𝑠𝑡 𝐶𝑎𝑠𝑒

6

Page 8: Software Estimation - part 2 of 2

Estimation Techniques

Structured Expert Judgment (Groups) Group Reviews▪ Individual estimates + discussions on differences to

reach consensus that the whole group accepts Wideband Delphi▪ Anonymous individual estimates, discussions on

differences, re-estimations, voting on keeping the average until consensus

Planning Poker▪ Anonymous individual estimates ▪ (cards played by every member), ▪ discussions until consensus. ▪ Egg timer / coffe break card

Page 9: Software Estimation - part 2 of 2

Estimation Techniques

Decomposition & Recomposition

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.

Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities.

Page 10: Software Estimation - part 2 of 2

Estimation Techniques

Proxy-Based Estimates

Fuzzy logic - estimate program size (LoC)▪ Classify features as Very Small, Small, Medium, Large, Very

Large▪ Use historical data about size of the average feature

Standard components - low-effort technique – estimate size in a project's early stages▪ Relevant elements to count in your previous systems

(dynamic Web pages, static Web pages, files, database tables, business rules, screens, reports…)

▪ Compute the average size per component for your past systems.

Page 11: Software Estimation - part 2 of 2

Estimation Techniques

Proxy-Based Estimates (continued)

Story points - obtain early estimates of an iterative project's effort and schedule (based on data from the same project)▪ Powers of 2 / Fibonacci

T-shirt sizing - help nontechnical stakeholders rule features in or out in the wide part of uncertainty.▪ Developers classify each feature's size as Small, Medium, Large, or

Extra Large (effort scale). ▪ In parallel, the customers & nontechnical stakeholders classify

each feature's business value on the same scale (value scale). ▪ These two sets of entries are then combined into „net business

value” numbers.

Page 12: Software Estimation - part 2 of 2

Next

How to Present EstimatesHow to Debate & Negotiate

Estimates

Page 13: Software Estimation - part 2 of 2

Estimates Presentation Styles Allow for tighten-up of estimates as you

move further into the project

Include uncertainty in your estimates – no, it’s not just being nice – it's part of a software professional's ethical responsibility

Always document and communicate the assumptions embedded in your estimate

Page 14: Software Estimation - part 2 of 2

Politics, Negotiation, Problem Solving

Be aware of external influences on the target. Understand (and communicate that you understand) the business requirements and their importance

Understand that executives are assertive by nature and by job description, and plan your estimation discussions accordingly

You can negotiate the commitment, but don't negotiate the estimate

Page 15: Software Estimation - part 2 of 2

Problem Solving and Principled Negotiation

Estimation discussions = problem solving, not negotiation.

All project stakeholders are on the same side – everyone wins, or everyone loses

Attack the problem, not the people

Generate as many planning options as you can to support the project goals

Page 16: Software Estimation - part 2 of 2

Problem Solving and Principled Negotiation

While in an atmosphere of collaborative problem solving, don't make commitments based on off-the-cuff estimates

Discussion deadlocks? Return to the question:

"What would be best for our organization?"

Page 17: Software Estimation - part 2 of 2

Thank you!

End of PART 2 of 2

Bio:

Software Estimation: Demystifying the Black Art by Steve McConnell Microsoft Press, 2006