Difference between revisions of "Estimate"
m (}) |
(+= {{quote|When we praise and glorify the team working late to meet speculative estimates, we destroy life and corrupt the culture of the company|@zenagilist}}) |
||
Line 1: | Line 1: | ||
{{quote|When we praise and glorify the team working late to meet speculative estimates, we destroy life and corrupt the culture of the company|@zenagilist}} | |||
{{quote|Just start referring to “estimates” as lies. “How long will that take?” “Well, if I had to lie, a week?”|@trek}} | {{quote|Just start referring to “estimates” as lies. “How long will that take?” “Well, if I had to lie, a week?”|@trek}} | ||
Revision as of 12:27, 2 September 2015
- When we praise and glorify the team working late to meet speculative estimates, we destroy life and corrupt the culture of the company
- Just start referring to “estimates” as lies. “How long will that take?” “Well, if I had to lie, a week?”
- Alternative to estimates: do the most important thing until either it ships or it is no longer the most important thing.
- In preparing for [projects] I have always found that [estimates] are useless, but [estimating] is indispensable.
- It’s better to be roughly right than precisely wrong
We keep on estimating and planning according to those estimates, expecting to meet deadlines and firing the wise fools that question the practice, and report the actual numbers that are not accepted by management. However…
- Insanity: Doing the same thing over and over and expecting different results.
- Ask, “Is the estimate useful?” rather than “Is the estimate right or wrong?”
Watch out for:
- Estimates become targets.
Use yesterday’s weather, which implies “results from the past give guarantees for the future”.
Collect metrics about the real system, like average lead time distribution, cumulative flow diagram, average throughput, and predictability.
Thou shalt not treat estimates as commitments.
Setting deadlines and promises based on estimates is dysfunctional.
The problem with estimates isn’t so much the concept of estimates themselves—because they are fine if we know that they are estimates—but that the way we treat them in software is not like an estimate. They drive deadlines and they drive promises and because of this, we get all kinds of problems.
Sources
- → budget
- → metrics drive behavior
- → relative estimation
- → plastic plan
- The IT Risk Manager » Vasco Duarte » No Estimates—How To Measure Project Progress Without Estimating
- The IT Risk Manager » Chris Matts » Cynefin and Estimates
- David J Anderson & Associates » David Anderson » The #NoEstimates Beef! And Agile's Trojan Horse
- #noestimates Twitter » Twitter/#noestimates
- Wikipedia » Probabilistic method
- InfoQ » Magne Jorgensen » What We Do and Don't Know about Software Development Effort Estimation
- Software Development Today » Vasco Duarte,Joseph Perline » Story Points Considered Harmful—Or why the future of estimation is really in our past…
- InfoQ » Agile Project Estimation and Planning
- Focused Objective » Troy Magennis » Forecasting Error: Not Accounting For Scope Increase
- Liz Keogh » Estimating Complexity see also cynefin
- InfoQ » Dimitar Bakardzhiev » #NoEstimates Project Planning Using Monte Carlo Simulation
- InfoQ » Dimitar Bakardzhiev » #noestimates Project Planning Using Monte Carlo Simulation
- Codemanship » Jason Gorman » My First, Last & Only Blog Post About #NoEstimates
- Ron Jeffries » Steve McConnell on #NoEstimates
- Construx » Steve McConnell » #NoEstimates - Response to Ron Jeffries
- Ron Jeffries » Continued Discussion with Steve McConnell
- @zenagilist
- @trek
- Kent Beck
- General Dwight D. Eisenhower
- Maynard Keynes
- Albert Einstein
- Chris Matts
- Esther Derby
- The IT Risk Manager
- Vasco Duarte
- David J Anderson & Associates
- David Anderson
- Wikipedia
- InfoQ
- Magne Jorgensen
- Software Development Today
- Joseph Perline
- Focused Objective
- Troy Magennis
- Liz Keogh
- Dimitar Bakardzhiev
- Codemanship
- Jason Gorman
- Ron Jeffries
- Construx
- Steve McConnell