The Estimation Process Moringa Devshop http://moringadevshop.com/ Chencha Jacob, Andreas Szenasi @jchex 

What is an estimate An approximate calculation or judgment of the value, number, quantity, or extent of something. 

Why do we estimate 1. Plan budget 2. Schedule project periods 3. Make reasonable commitments 

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) 

Project size Total scope of a project. Includes breadth and depth of the feature set. As well as the program difficulty and complexity. 

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. 

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 

Precision vs Accuracy The only good kind of estimate is an accurate one. Failure to acknowledge imprecision is a sign of a bad estimate. 

Examples Bad Things To Estimate 1. Lines of Code 2. Key Strokes/Hour Vary wildly between developers and languages 

Hofstader’s law Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. 

Tracking progress Velocity Burndown chart Iteration burndown chart 

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. 

Schedule estimation schedule in months = 3.0 * man- months 1/3 

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. 

Schedule Compression schedule compression factor = desired schedule ÷ initial schedule 

Schedule Compression 2 Your estimate: 5 months Man Month estimate: 15 Months What client wants: 4 Months Schedule compression factor = ⅘ = 0.8 

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 

Effects of compression compressed schedule effort = initial effort ÷ schedule compression factor Compressed schedule effort = 15 / 0.8 = 18.75 Man Months 

Maximum compression Communications and management overhead ensure a maximum ceiling on compression. Maximum compression 0.75 (Boem 1981) 

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 

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) 

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