1. 1 Agile Estimating and Planning October, 2013 Technion, Israel Prof. Fabio Kon University of Sao Paulo, Brazil kon@ime.usp.br

2. 2 Non-Agile World No Plans Excess of Plans  --------- 

3. 3 How much to plan Plan too much is waste Plan too little = lack of organization/focus

4. 4 Some data from Chaos report (2004) 18% 29% 53% Success failures Challenged

5. 5 Chaos report 19942004 Projects not completed ------------ 31% Projects succedded ----- 16% Avg. budget consumed -----------------------> 280% Avg. time needed -----------------------> 264% Projectos not concluded ------- 18% Projects succedded ----------- 29% Avg. budget consumed ---------------> 156% Avg. time needed -------------> 84%

6. Disclaimer The Chaos report is not very scientific Use with caution

7. Which software to develop? Never or Rarely Used 64% Tov Meod 36% Source: Jim Johnson, 2000 Features:

8. 8 Attention! In real life, you can be sure of only one thing: things will change and not follow the plan Be prepared for that!

9. 9 Agile Approach Individuals and interactions Working Software Customer collaboration Adaptation to change is more important than following the initial plan - - - x - - - Plans are nothing; planning is everything Eisenhower

10. 10 Scope of Agile Planning Planning Onion

11. 11 Release planning What to do List stories that will be developed Select the stories that will be included in the release Estimate stories What not to do Assign responsibilities Define a sequence Create tasks for each story High-level planning

12. 12 Iteration planning Customers, programmers, analysts, designers, etc. Identify needed tasks for each story Manage tasks using online tool or paper cards Estimate each task Do not allocate tasks to people (yet)

13. 13 Uncertainty cone

14. 14 Benefit of (good) Estimates Reduce risk Reduce uncertainty Help in decision making Establishes trust Transmit information/knoweledge

15. 15 Why plans fail? Planning is done task by task and added up  Activities are not independent  Delays add up  Activities are never completed before the deadline Parkinson law (1993)‏ Many tasks in parallel decrease productivity Features are not developed in order of priority Uncertainty is normally ignored Estimates become commitments

16. 16 Preparing to estimate Avoid false precision Define a scale, e.g.:  1, 2, 3, 5 and 8  0, 1, 2, 4 and 8  10, 20, 30, 50, and 100 Identify Stories, Themes, and Epics

17. 17 Let’s estimate! Size is different from Duration 1 1 2 2 2 2 4 4 4 4 8 16 2 Total = 58

18. 18 Estimating with Points – Relative estimates – Abstract – Measures size of effort (must be converted to time) with Ideal Work Days – Easier to explain – Concrete – My favorite when doable

19. 19 Why ideal ≠ real Meetings Bug fixing Special projects Support Demonstration Training Revisions Interviews Task switching Phone calls E-mails Personal issues Sicknesses Extraordinary boss requests 1 real day = α ideal day, 0 < α < 1

20. 20 How to estimate Major techniques:  Expert opinion  analogy  Divide and conquer Major problems:  Availability of expert  Estimator is not developer  Estimate by feature and not by task Solution: Planning Poker

21. 21 Planning Poker

22. 22 Estimating Velocity Based on history / previous experience Carrying out 1 iteration

23. 23 First Plan The first iteration is likely to be very wrong. Don’t worry, learn, and adapt, correct your estimates. … at least, the 1 st iteration is done only once ;-)

24. 24 Protection against uncertainty Always add a buffer! Lag in schedule Buffer in estimates Buffer in features

25. 25 Scheduling Prioritize based on Business Value Consider:  Financial value of the functionality  Cost of development and maintenance  Development time  Amount of learning and knowledge offered by the new feature  Amount of risk eliminated after developing the functionality  Technical dependencies

26. 26 Value and Risk High Low RISKRISK Value Avoid Do Last Do First Do Second

27. 27 Prioritizing Customer Desires Kano Model for Customer Satisfaction Required features Aggregating features Surprising features

28. 28 Project Monitoring Estimates will be very wrong in the beginning Will get better as team become more experienced It’s important to monitor progress to:  Know where you are  Learn and then estimate better

29. 29 Release Burndown Chart

30. 30 Release Burndown Bar Chart

31. 31 12 Rules for Planning with Agility (I)‏ 1. Involve the whole team 2. Plan in multiple levels 3. Keep size and time estimates separate (optional) 4. Consider uncertainty for features and dates 5. Replan frequently 6. Track and advertise progress

32. 32 12 Rules for Planning with Agility (II)‏ 1. Be aware of the importance of learning 2. Work with features of the right size 3. Prioritize features 4. Base your estimates and plans in facts 5. Not plan for 100% of the time (buffer, ideal work day) 6. Coordinate planning to avoid dependencies

33. 33 Questions Fabio Kon kon@ime.usp.br University of São Paulo, Brazil Bibliography: Agile Estimating and Planning. Mike Cohn. Pearson Education. 2005.