Part VI Why Agile Planning Works

Transcription

1 Part VI Why Agile Planning Works Purpose of Planning Reasons why Agile estimating and planning works Chapter 22: Why Agile Planning Works If you want a guarantee, buy a toaster. Clint Eastwood in The Rookie Planning attempts to identify the optimum development solution involving features, resources and schedule Change any one causes changes in the others 1

2 Replanning Occurs Frequently There is no perfect plan! The Release plan is updated either after each iteration or, at worst, after every few iterations. our knowledge is always incomplete and requires that plans be revised as we learn. we replan to remove imprecision in the previous plan. 2

3 Estimates of Size and Duration are Separated Size of effort and time needed to complete the effort are related but are not the same additional factors affect the time needed Author s analogy You are asked to estimate how a book it will it take you to read it You do not have the book to inspect First, estimate the number of pages 600 (size / effort) Estimate your rate of progress one page per minute (velocity) How long is estimated as 600 minutes 10 hours (duration) 3

4 Release Plans are Made at Different Levels Benefits: Iteration Current Day 1. Different plans created for different reasons Daily plan is precise team members commit to work for that day Iteration plan is less precise user stories to be developed and the tasks necessary to do so Release plan is the least precise prioritized list of desired user stories or how much desired functionality is likely to be delivered by the desired release date 2. Provides 3 different ways to view the project Time horizons and degrees of precision are different at each level Iteration plan guides the team in completing the work within a short iteration Release plan provides perspective (the context and focus) for the iteration work ensuring that short-term goals are consistent with the longer-term goal 4

5 Plans are Based on Features, Not Tasks Tasks are the focus of: Gantt Charts, PERT (Program/Project Evaluation and Review) Charts, or Work Breakdown Structure (WBS) Agile focus is on Features the right level agile planning is better planning because it utilizes features (stories, etc.) rather than tasks. It is easy to plan an entire project using standard tasks without really understanding the product being built. Jim Highsmith 5

6 Small Stories Keep Work Flowing Think of cycle time Amount of time something takes to go from the start of a process to the end of that process The time work begins on a feature until that feature delivers value to the users The shorter the cycle time the better Variability exists in the time needed to develop a new feature How to reduce the variability Work in small and similar size units Large stories (features) disaggregated into smaller pieces Magnitude of the work associated with the smaller pieces should be relatively the same varying only in roughly one order of magnitude 6

7 Work in Process is Eliminated Every Iteration At the start of the next iteration, there is no carry-over work from the previous iteration Work not completed in the last iteration may or may not be carried over to the next iteration All work is completed means a shorter feedback loop from users to the project team Benefits are faster learning as well as timely risk mitigation and control 7

8 Tracking is at the Team Level Traditionally, measure and reward progress at the individual level for each team member Promotes dysfunctional behavior Programmer finishing early could be accused of padding his or her estimate with the result work is never completed early No individual Burndown Charts 8

9 Uncertainty is Acknowledged and Planned For Traditional planning do not allow changes unless approved through an onerous Change Control Process When we create a plan early in a project and do not update the plan as we acquire new knowledge, we lose the opportunity to synchronize the plan with reality. Uncertainty is dealt with from iteration to iteration End Uncertainty (about the product being built) Feedback from users & stakeholders at the end of each iteration Built into plans for subsequent iterations Means Uncertainty (about how the product will be built) Team learns more about the technologies in use and can adjust in subsequent iterations 9

10 1. Involve the whole team A Dozen Guidelines The more responsibilities shared, the more success shared 2. Plan at different levels Release, iteration & daily cover different levels of precision and purpose 3. Keep estimates of size and duration separate y using different units. Story Points for size and translating size into duration using velocity 4. Express uncertainty in either the functionality or the date For fixed functionality, use a date range for fixed date, use a range of functionality that will be included The greater the uncertainty, express the uncertainty in bigger units (iterations, months, then quarters) 5. Replan often 10

11 6. Track and communicate progress Keep them informed! Burndown charts and other at-a-glance indicators 7. Acknowledge the importance of learning Update plans to include what has been learned As more is learned about customer needs, new features can be added As more is learned about technologies being used and working as a team, adjust rate of progress and the team s desired approach 8. Plan features of the right size Decompose functionality to be added in the next few iterations Estimate more distant work at the theme level do not decompose large stories into small ones too far in advance 9. Prioritize features Order of work should reflect the relative value of the work Also, consider learning and risk reduction as priorities 11

12 10. Base estimates and plans on facts Estimating and re-estimating velocity is an example (Chapter 16) Estimating how much of a feature is complete it is either 0% or 100% 11. Leave some slack Do not plan on using 100% of every team member s time Do not assume full capacity work is sustainable 12. Coordinate teams through lookahead planning When multiple teams are involved and inter-team dependences exist 12

13 Orders of Magnitude Refers to scale of the relationships between numbers Usually applies to a scale of 10 Order of Magnitude represented as powers of ten 100 is larger than 10 by one order of magnitude 1700 is larger than 17 by two orders of magnitude. 842 and 815 are on the same order of magnitude, even though they are not equal. Return 13