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.
What are typical steps within the Cone of Uncertainty?
- Initial Concept
- Approved Product Definition
- Requirements Complete
- User Interface Design Complete
- Detailed Design Complete
What is the relationship between the Cone of Uncertainty and Commitment?
Committing too early in the Cone means the project will fail. Project Managers can navigate projects if the estimate is within 20% of the project’s reality, so meaningful commitments can be done around 30% in the project (after some work has been done)
What is the relationship between the Cone of Uncertainty and Iterative Development?
Iterative Development creates “mini-cones” for each current feature, which means that the cone for that feature can be reduced in a few days.
However, this means that the overall cone for other features will not narrow down until an interation starts.
A middle ground can be to reduce the cone in a sequential way before switching to iterations - but that depends on the priorities of the business (Flexibility of switching features vs predicatbility of outcome)
What is the relationship between chaotic processes and estimation?
Better estimation pracitces alone do not provde more accurate estimations for chaotic projects. You can’t accurately estimate an out-of-control process. As a first step, fixing the chaos is more imporant than improving the estimates.
What is the relationship between unstable requirements and estimates?
- Unstable requirements can be part of process chaos, so the cone will never narrow
- Additionally, these requirements are often not re-estimated, or new requirements come in but are not accounted for, so the project runs late even if the (initial) estimates where good
- To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.
- Additionally, the original estimates can be buffered to account for late requirement additions (for example: add 50% buffer on the sum of overall estimates)
Which categories of activities are usually omitted during estimation?
- Missing requirements
- Missing software-development activities
- Missing non-software-development activities
Why should also very tiny requirements be included in the estimates?
As nothing can be built for free, the estimates should not imply that it can.
Why are developer estimates usually too optimistic?
Developer Estimates are usually 20%-30% too optimistic. Reasons include:
- We’ll be more productive on this project than we were on the last project
- A lot of things went wrong on the last project, not so many will go wrong on this project
- We started the project slowly and learned a lot of lessons the hard way, but all the lessons will allow us to finish the project much faster than we started it
What is the Diseconomy of Scale and how does it relate to Estimates?
The Diseconomy of Scale means that when a software grows linearily in size, the number of communication paths between people involved (and sometimes modules written) increases as a squared function.
This means, the bigger a system, the greater the cost of each unit (and therefore the estimate).
It also means that as the project scales up linearily, the efforts go up exponentially.
Therefore, two projects/estimates can not be easily compared if those projects differ a lot in size
