Agile Estimating and Planning October, 2013 Technion , Israel

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

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

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

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

5. Chaos report 1994 2004 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? Features: Tov Meod 36% Never or Rarely Used 64% Source: Jim Johnson, 2000

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. 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. Scope of Agile Planning Planning Onion

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

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. Uncertainty cone

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

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. 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. Let’s estimate! Size is different from Duration 8 16 4 1 4 2 2 4 Total = 58 2 1 2 2 4 16

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

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

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. Planning Poker

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

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

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

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. Value and Risk High RI SK Do First Avoid Do Last Do Second Low High Value

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

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. Release Burndown Chart

30. Release Burndown Bar Chart

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

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

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