## Why Estimate? Estimation is important as it allows us to gain a better grasp of the issue at hand, engage in discussions about possible solutions, make preliminary choices, and aids in the organization and management of the project. The Test Architect plays a significant role in estimation, particularly when it comes to predicting the scope of testing activities. ## Underestimation Underestimation usually refers to the act of assessing something based on its cost rather than its functionality. This can lead to exceeding the budget and schedule. ## Overestimation Overestimation refers to the act of making an assessment or calculation that is too high in relation to the actual value or number. In a business context, overestimation could relate to aspects such as project timelines, costs, resources required, expected revenues, etc. This usually happens when there is a lack of accurate data or due to optimistic assumptions and forecasts. ### What is overestimation and the results of it? - [[Parkinson's Law]] - Gold-Plating / Over-Engineering hampers business plan - Risk: Loss of contracts ## Estimate Sanity Check The Estimate Sanity Check is the checklist that we can use to assess the maturity of the estimation process on our project. The following sanity check indicates how useful your current project estimate is likely to be in managing your project. For each Yes answer, give the estimate one point. 1. Was a standardized procedure used to create the estimate? 2. Was the estimation process free from pressure that would bias the result? 3. If the estimate was negotiated, were only the inputs to the estimate negotiated, not the outputs or the estimation process itself? 4. Is the estimate expressed with precision that matches its accuracy (e.g., is the estimate expressed as a range or coarse number if it's early in the project?) 5. Was the estimate created using multiple techniques that converged to similar results? 6. Is the productivity assumption underlying the estimate comparable to productivity actually experienced on past projects of similar sizes? 7. Is the estimated schedule at least 2.0 x StaffMonths 1/3? (That is, is the estimate outside of the Impossible Zone?) 8. Were the people who are going to do the work involved in creating the estimate? 9. Has the estimate been reviewed by an expert estimator? 10. Does the estimate include a nonzero allowance for the impact that project risks will have on effort and schedule? 11. Is the estimate part of a series of estimates that will become more accurate as the project moves into the narrow part of the Cone of Uncertainty? 12. Are all elements of the project included in the estimate, including creation of setup program, creation of data conversion utilities, cutover from old system to new system, etc.? - Scores of 10-12 indicate estimates that should be highly accurate. - Scores of 7-9 indicate estimates that are good enough to provide project guidance but that are probably optimistic. - Score of 6 or below indicate estimates that are subject to significant bias, optimism, or both, and are not accurate enough to provide meaningful guidance to managing a project. --- Source: This Estimate Sanity Check is from "Software Estimation" by Steve McConnel (Microsoft Press, 2006) and is 2006 Steve McConnell. All Rights Reserved. Permission to copy this quiz is granted provided that this copyright notice is included. ## Estimation Method Classification - **Analogy / Expert estimation methods** - Estimations based on experience with similar products or technologies - **Engineering Estimation Methods** - Estimation based on a detailed examination of product components and process flows - **Algorithmic Estimation Methods** - Estimation based on equations with variables and parameters, usually using historic (experience) data and statistical methods (e.g., function point analysis, %-method) ## Size Estimation ### Why? Estimating size - improves the accuracy of estimations - enables tracking of progress - permits the utilization of external data from past experiences - makes gathering and application of historical data easier ### When? - Not all work packages require or are suitable for size estimation. Does size measurement have an influence on the estimation accuracy? ![[Pasted image 20220209113256.png]] ## Cone of Uncertainty  ## Basic Schedule Equation ![[Pasted image 20220209114226.png]] Program level: - Objective - Preliminary approximation of Epics and Features for business decision-making, ranking, and outlining - Selection of subjects for the program increment planning based on team's capability - Initial estimation by Feature owner and architect or lead developers - Features that need to be included in the program increment should be roughly estimated by the team Team level: - Objective: Avoid overloading the iteration, ensuring the iteration commitment is maintained - Items that need consideration in the iteration planning require a more reliable level of estimation compared to items at the program level ## Estimation Factors - Quantity (How much of code to test?) - Uncertainty (New technology / domain risk) - Complexity (Business logic, architecture, algorithm) ## Estimation Dos - Consider all 3 factors (effort, complexity & uncertainty) - Be realistic - Determine a common understanding of a story point - Split User Stories that are larger that 1 DW - Small stories provide an easier way of progress tracking and faster feedback ## Estimation Don'ts - Do not focus on one factor only - Neither be optimistic nor pessimistic - Using multiple, varying understandings of story points - Do not keep large User Stories --- ## Tags: #Estimation #ProjectManagement #Overestimation #Underestimation #SizeEstimation #ConeOfUncertainty #ScheduleEquation