Estimations: hit the target. Tips & Technics
Download as PPTX, PDF•0 likes•139 views
The document provides tips and techniques for software estimation. It discusses defining estimates, factors that influence accuracy such as probability statements and the cone of uncertainty. The primary purpose of estimation is to determine if targets are realistic rather than perfectly predicting outcomes. Techniques covered include counting elements to estimate, using historical data for calibration, individual expert judgement breaking tasks into appropriate levels of detail, analogy to past projects, and group expert judgement. Accuracy improves with proper technique selection, assumptions documentation, and incorporating lessons learned.
Estimations: hit the target. Tips & Technics
- 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.
- 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
- 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
- 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
- 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
- 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
- 45. 6. Expert Judgment in Groups
- 46. 6. Expert Judgment in Groups