Critical Estimation Concepts Flashcards
What is a target?
A target is a statement of a desirable business objective. Such as: “We need to have Version 2.1 ready to demonstrate at a trade show in May” It is not an estimate, but the estimate can help finding out if the target can be hit.
What is a commitment?
A commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. It can be the same as an estimate, or more aggressive, or more conservative.
What is an estimate (Dictionary Definition)?
Dictionary Definition:
1) A tentative evaluation or rough calculation
2) A preliminary calculation of the cost of a project
3) A judgement based upon one’s impressions; opinion
Which concepts are closely related to and often confused with estimates?
Targets, which are business objectives, and Commitments, which are promises. They can be the same, but don’t have to be.
What is the relationship between Estimation and Planning?
They are related, but estimation is not planning, and planning is not estimation.
Estimation should be unbiased and analytical, with accuracy as the goal.
Planning is done to seek a particular result, to achieve a specific outcome. We plan specific means to reach a specific end.
Estimates form the foundations of a plan. If Estimates differ dramatically from the targets, the project plan needs to account for the high risk.
How can you avoid miscommunication around Estimates, Targets and Commitments?
When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.
Red flags are statements like: “How long will this take? We need to have it delivered by March”
How is Project Outcome vs. Estimate distributed?
Not as a bell curve: It has a hard stop on the left side since there is a lower limit about how much needs to be done, but there is no limit on the right side.
How should single estimates be treated?
Not as estimates, as they are lacking information about the probability. Ask about a range, or about the best case vs. worst case.
How can probability in estimates be expressed?
Either directly (“90% confident with a 24 week schedule”) or as a range (“18-24 weeks”) or with best/worst case (“Best case: 18 weeks. Worst case: 24 weeks”)
What is usually the real purpose of Estimations?
It’s not about predicting a project’s outcome, it’s to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
It’s as if packing for a trip. Will the clothes for the trip fit in a small suitcase, maybe with minor adjustments, or are we forced to take a bigger suitcase? Project Managers normally don’t want an estimate that tells them that the clothes don’t fit, they want a plan for making as many of the clothes fit as possible.
What is a good 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.
How should estimates with a confidence (like 90%) be treated?
With caution - confidences should only be set if there is a quantitative basis, otherwise it is wishful thinking
How wide should you make your ranges?
Ranges are usually done too narrow. They should not misrepresent the confidence in the estimates (for example, little confidence in a range of 6-7 hours is worth less than high confidence in a range of 4-16 hours)
Where does the pressure to use narrow ranges come from?
Often from the inside, professional pride or to give the impression that a narrower range represents a better estimate.
Why are narrow ranges bad?
They come from the misconception of Precision vs Accuracy, which are often mixed up.
A precise estimate is like 8h, 2 mins, 3 seconds. Very precise, but not very accurate
An accurate estimate is like “it will be done in the future”. Very accurate, but not very precise.
By giving a high precision, people get the feeling that the estimate is also very accurate.
What is Parkinson’s Law and how does it relate to Estimates?
Work will expand to the available time.
The fear is that if developers overestimate, they find ways to use the additional time.
This might be true, but the cost for overestimation is linear and bounded - work expands to fill the available time, but no further. The cost for underestimation is nonlinear and unbounded, it causes delays, defects and hard to predict costs.
This should be tackled with better project control, not with intentional underestimation.
What is the Student Syndrome and how does it relate to Estimates?
It’s the assumption that if developers are given too much tiem, they procrastrinate until late in the project, then they rush to complete their work and probably won’t finish the project on time.
However, this can be solved more efficiently through active task tracking and project control and not through changing the estimates.
What are typical arguments against overestimation?
- Student’s Syndrome
- Parkinson’s Law
- Missing sense of urgency
What are typical arguments against underestimation?
- Reduced chance of on-time completion
- Reduced effectiveness of project plans
- Poor technical foundation
- Destructive late-project dynamics make the project even worse
What is the software industry’s problem with estimate and what are the consequences?
The software industry has an underestimation problem. The consequence is that estimates will get bigger as they get more accurate.
What are the benefits of accurate estimates?
- Improved status visibility
- Higher quality
- Better coordination with nonsoftware functions
- Better budgeting
- Increased credibility for the development team
- Early risk information
How important is the predictability of a project in comparison to other factors such as functionality and cost?
It usually is much more important. People prefer a predictable feature even if it takes a bit longer, because the business can depend on it.
Many businesses value predictability more than development time, cost or flexibility.
What is the problem with “intuition” and “guessing” as an estimation technique?
Even for skilled developers these estimates are usually not accurate.
60%-85% of all estimates are based on guessing, intuition, unstructured expert judgement, informal analogies and similar techniques.
These have been found to corellate with cost and schedule overruns.
What is the Cone of Uncertainty?
A representation of the best case of variablility in estimates at a certain stage of Software Development. As the project moves along, the cone gets narrower.
Since this is a best case representation, working on the estimate cannot make it more accurate than the cone, instead, the software definition needs to be refined.
The cone doesn’t narrow itself - decisions need to be taken to remove the variability from the project.
