Difference between revisions of "Estimate"
Jump to navigation
Jump to search
(+= {{quote|Estimates become targets.|Esther Derby}}) |
(Use {{p|yesterday’s weather}}) |
||
Line 8: | Line 8: | ||
Watch out for: | Watch out for: | ||
{{quote|Estimates become targets.|Esther Derby}} | {{quote|Estimates become targets.|Esther Derby}} | ||
Use {{p|yesterday’s weather}}, which implies “results from the past give guarantees for the future”. | |||
Collect metrics about the real system, like {{p|average lead time distribution}}, {{p|cumulative flow diagram}}, {{p|average throughput}}, and {{p|predictability}}. | |||
*→ {{p|metrics drive behavior}} | *→ {{p|metrics drive behavior}} |
Revision as of 17:12, 7 September 2014
- 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.
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.
- → metrics drive behavior
- → relative estimation
- http://www.djaa.com/noestimates-beef-and-agiles-trojan-horse
- #noestimates
- http://en.wikipedia.org/wiki/Probabilistic_method
- http://www.infoq.com/articles/software-development-effort-estimation
- http://softwaredevelopmenttoday.blogspot.co.nz/2012/01/story-points-considered-harmful-or-why.html
- http://www.infoq.com/resource/minibooks/emag-agile-estimation/en/pdf/Agile-Project-Estimation-and-Planning-eMag.pdf
See plastic plan.