Estimation Process

The background and theory behind the estimation practises presented in the workshop.

Transcript

1. The Estimation Process Moringa Devshop http://moringadevshop.com/ Chencha Jacob, Andreas Szenasi @jchex
2. What is an estimate An approximate calculation or judgment of the value, number, quantity, or extent of something.
3. Why do we estimate 1. Plan budget 2. Schedule project periods 3. Make reasonable commitments
4. Steps in Estimation 1. Estimate Project Size (Function points, Story points) 2. Estimate the Effort (Developer hours, Man Month) 3. Estimate the Schedule (Calendar dates)
5. Project size Total scope of a project. Includes breadth and depth of the feature set. As well as the program difficulty and complexity.
6. Project Effort One person's working time for a month, or the equivalent, used as a measure of how much work or labor is required or consumed to perform some task.
7. Our Assumptions 1. Non trivial program 2. Efficient use of programming tools 3. Use of modern programming practices 4. Active risk management 5. Excellent physical environment 6. Integrated use of communication tools 7. Use of agile techniques
8. Precision vs Accuracy The only good kind of estimate is an accurate one. Failure to acknowledge imprecision is a sign of a bad estimate.
9. Examples Bad Things To Estimate 1. Lines of Code 2. Key Strokes/Hour Vary wildly between developers and languages
10. Hofstader’s law Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
11. Tracking progress Velocity Burndown chart Iteration burndown chart
12. Velocity Velocity is quite a simple concept. It is the measure of the number of units of work a team completed in a given time interval. This is commonly measured in story points completed per sprint. Velocity is the sum of the estimates of delivered (i.e., accepted) features per iteration.
13. Schedule estimation schedule in months = 3.0 * man- months 1/3
14. Team size Optimal team size = schedule in months / number of months in schedule Bigger projects take longer, but they also have bigger teams; and the inefficiencies associated with larger team sizes mean that effort increases disproportionately faster than schedule.
15. Schedule Compression schedule compression factor = desired schedule ÷ initial schedule
16. Schedule Compression 2 Your estimate: 5 months Man Month estimate: 15 Months What client wants: 4 Months Schedule compression factor = ⅘ = 0.8
17. No shortcuts “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.” ~ Fred Brooks
18. Effects of compression compressed schedule effort = initial effort ÷ schedule compression factor Compressed schedule effort = 15 / 0.8 = 18.75 Man Months
19. Maximum compression Communications and management overhead ensure a maximum ceiling on compression. Maximum compression 0.75 (Boem 1981)
20. Brooks Law Adding manpower to a late software project makes it later Why: 1. Ramp up time 2. Communication overhead 3. Limited divisibility of tasks
21. Estimation tips 1. Don’t be cornered into giving a quick estimate 2. Keep metrics on projects so that you have a benchmark to refer to 3. Use estimates given by the developers 4. Estimate at the smallest pieces possible (Law of large numbers) 5. Include common and easy tasks on your estimates 6. Give a range rather than a point estimate 7. Don’t be an optimist (Refer Hofstader’s)
22. Resources http://www.jamesshore.com/Agile-Book/estimating.html https://www.versionone.com/agile-101/agile-project-management-customer-management-best-practices/agile- scrum-velocity/ https://www.scrumalliance.org/community/articles/2013/august/burn-down-chart-%E2%80%93-an-effective-planning- and-tracki http://blog.chenchatech.com/2016/04/estimating-with-limited-information/ http://blog.chenchatech.com/2016/03/invest-in-user-stories/ Mythical Man Month Software Engineering Economics