330 likes | 468 Views
Prof. Fabio Kon University of Sao Paulo, Brazil kon@ime.usp.br. Agile Estimating and Planning October, 2013 Technion , Israel. Non-Agile World. No Plans. --- --- --- . Excess of Plans. How much to plan. Plan too much is waste Plan too little = lack of organization/focus.
E N D
Prof. Fabio Kon University of Sao Paulo, Brazil kon@ime.usp.br Agile Estimating and PlanningOctober, 2013 Technion, Israel
Non-Agile World No Plans --------- Excess of Plans
How much to plan • Plan too much is waste • Plan too little = lack of organization/focus
Some data from Chaos report(2004) Success 29% 53% 18% Challenged failures
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%
Disclaimer The Chaos report is not very scientific Use with caution
Which software to develop? Features: Tov Meod 36% Never or Rarely Used 64% Source: Jim Johnson, 2000
Attention! In real life, you can be sure of only one thing: things will change and not follow the plan Be prepared for that!
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
Scope of Agile Planning Planning Onion
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
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)
Benefit of (good) Estimates • Reduce risk • Reduce uncertainty • Help in decision making • Establishes trust • Transmit information/knoweledge
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
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
Let’s estimate! Size is different from Duration 8 16 4 1 4 2 2 4 Total = 58 2 1 2 2 4 16
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)
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
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
Estimating Velocity • Based on history / previous experience • Carrying out 1 iteration
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 ;-)
Protection against uncertainty Always add a buffer! • Lag in schedule • Buffer in estimates • Buffer in features
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
Value and Risk High RI SK Do First Avoid Do Last Do Second Low High Value
Prioritizing Customer Desires Kano Model for Customer Satisfaction • Required features • Aggregating features • Surprising features
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
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
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
Questions Fabio Kon kon@ime.usp.br University of São Paulo, Brazil Bibliography: Agile Estimating and Planning. Mike Cohn. Pearson Education. 2005.