1. (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Training Solutions Agile Planning v. 7.12.1

2. Agile Planning and Planning 2 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Dilbert on Project Planning

3. Agile Planning and Planning 3 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Agenda ► Planning  Planning Wisdom  Traditional Planning  Agile Planning  3 levels of Agile Planning ► Agile Release Planning  Backlog Prioritization  Story Sizing  Creating the Release Plan  Maintaining the Release Plan ► Agile Iteration Planning  Commitment-base Iteration Planning  Velocity-based Iteration Planning

4. Agile Planning and Planning 4 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Only 16% of projects finished on-time, on- budget with originally defined scope Most traditional plans fail… Only 16% of projects are delivered… On-Time… On-Budget… All defined scope… Source: Standish Report, 1994

5. Agile Planning and Planning 5 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved ► Planning by activity rather than by feature  Lateness passed down schedule ► Multitasking  Negative effects on productivity are typically not accounted for ► Features not developed by priority  Important features often left until later and dropped if schedule not met ► Uncertainty is ignored  Development is highly dynamic endeavor ► Estimates become commitments and are used against developers  These usually start as “guesstimates” but later perceived as promises ► Highly dependent on early, error-prone estimates  Traditional plans are typically estimate-driven Why do traditional plans fail?

6. Agile Planning and Planning 6 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved 300100160 Estimating Troubles Impact of Client Expectations on Estimates No Info GROUP 1 Control hours Estimate: 40 hours GROUP 2 Low hours told: Estimate: GROUP 3 High hours 800 hours told: Estimate: Experienced software developers were divided into 3 groups  Group 1 – Not told about client opinion  Group 2 – Told that client believed a low level of effort was required  Group 3 – Told that client believed a high level of effort was required  All groups were told to ignore client opinions and expectations Source: Jorgenen & Grimstad, 2007. How to Avoid Impact from Irrelevant and Misleading information when estimating software development effort

7. Agile Planning and Planning 7 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Estimating Troubles Impact of Irrelevant Information on Estimates Experienced software developers were divided into 2 groups  Both groups given the same requirements and instructions  Group 1 – No additional information provided  Group 2 – Provided with irrelevant information example: systems with which they do not need to integrate with  Asked to estimate the work 2 X Estimate (Hours) Group 2Group 1 Source: Jorgenen & Grimstad, 2007. How to Avoid Impact from Irrelevant and Misleading information when estimating software development effort

8. Agile Planning and Planning 8 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved 4025 Estimating Troubles Handling Irrelevant Information Source: Jorgenen & Grimstad, 2007. How to Avoid Impact from Irrelevant and Misleading information when estimating software development effort No Irrelevant Info GROUP 1 Control hours Estimate: Hidden Irrelevant Info GROUP 2 Hidden hours Estimate: 3540 Highlight Irrelevant Info GROUP 3 Identify hours Estimate: GROUP 4 Remove hours Estimate: Remove Irrelevant Info

9. Agile Planning and Planning 9 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved ► Parkinson’s Law  Work will fill the amount of time allotted to complete it ► Student Syndrome  Work will not begin until the latest possible opportunity Why do traditional plans fail? TaskSafety To have ANY chance of doing better than plan, developers must focus on completing task immediately. Traditional plans identify activities and completion dates. TaskSafety In reality, however, we procrastinate and don’t start the task until we feel there is just enough time left to get it done

10. Agile Planning and Planning 10 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Planning to do our worst ► “…if all goes perfectly…”  Activity based planning using Gantt charts allows us to only meet deadlines if all goes perfectly ► Adapts poorly to the reality  Poor ability to adapt to changing situations  Poor ability for targeted learnings ► Any slip in any task affects all subsequent tasks  Assumes that a slippage is localized and atypical ► Activities will start as late as possible (Student Syndrome)  Reduces ability to respond to change Using traditional planning methods, we are “planning to do our worst”

11. Agile Planning and Planning 11 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved What is a good plan? ► A good plan is one that supports reliable decision-making ► One that increases in accuracy and precision over time  We’ll be done in the fourth quarter  We’ll be done in November  We’ll be done November 7 th “It is better to be roughly right than precisely wrong.” -John Maynard Keynes “It is better to be roughly right than precisely wrong.” -John Maynard Keynes

12. Agile Planning and Planning 12 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved ► Focus on planning – not the plan ► Balance benefit and investment ► Adaptive to change and learning ► Plans are easily changed ► Planning is continuous throughout the project What makes planning Agile?

13. Agile Planning and Planning 13 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Different levels of planning Strategy Portfolio Product Release Iteration Day We will focus on these 3 planning areas

14. Agile Planning and Planning 14 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Release Planning

15. Agile Planning and Planning 15 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Release Planning Q. What do we need to start Release Planning? A. List of prioritized, sized stories  aka. Release Backlog  aka. Project Backlog  aka. Product Backlog The same techniques for a single release can be applied to multiple releases to derive a multi- release project plan PriorityStory Size 1As an investor, I want to… 2 3 4As a visitor I want to… 5As an investor, I want to… 6As a visitor I want to… 7 8An investor I want to… Release Backlog We don’t need ALL possible stories – just enough to at least roughly fill the desired timeframe Team Velocity  Use Historical Values  Use Actuals by running an iteration  Forecast or Derive

16. Agile Planning and Planning 16 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Prioritization

17. Agile Planning and Planning 17 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Prioritization Factors ► Financial Value of stories/features  Assign dollar-value to stories or features ► Cost of implementing (or not implementing!) stories/features  Consider cost now vs. cost of adding later  Also consider opportunity costs ► Amount and significance of learning and new knowledge created by the stories/features  Project (how?)  Product (what?) ► Amount of risk removed by developing the stories/features  Reduced project or product uncertainty ► Prioritize across “Themes” or “Features” individual stories that cannot clearly be “valued” Note: As long as the Product Owner is considering all these things appropriately, there is no need to formalize or overcomplicate prioritization Source: Mike Cohn, Agile Planning and Planning

18. Agile Planning and Planning 18 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Risk Anything that might happen that would jeopardize or limit the success of the project. Types of Project Risk: ► Schedule Risk  “We might not be done by October 21” ► Cost Risk  “We don’t have budget for more consultants” ► Functionality Risk  “We might not be able to develop sufficiently-flexible roles-based access” Note: Though technically “Risks” can have positive as well as negative impacts on projects – however typically the word “Risk” is not used to describe possible positive effects. As such, we will focus on the negative impact of “Risk”.

19. Agile Planning and Planning 19 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Risk-Value Prioritization Which stories should we work on first? High Risk Low Value High Risk High Value Low Risk High Value Low Risk Low Value Risk Value High Low High Tackle high-risk areas with big return. These likely aren’t worth doing EVER. Source: Mike Cohn, Agile Planning and Planning

20. Agile Planning and Planning 20 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved More about Prioritization ► Financial  New Revenue, Incremental Rev, Operating Efficiencies  Net Present Value, Internal Rate of Return, Payback Period, Discounted Payback Period ► Desirability  Must-haves  The More, the Better  Exciters “The indispensable first step to getting what you want is this: Decide what you want.” -Ben Stein “The indispensable first step to getting what you want is this: Decide what you want.” -Ben Stein MoSCoW Prioritization Technique Must Haves - Fundamental to the projects success o Should Haves - Important but the projects success does not rely on these Could Haves - Can easily be left out without impacting on the project o Won't Have - This time round can be left out this time and done at a later date MoSCoW Prioritization Technique Must Haves - Fundamental to the projects success o Should Haves - Important but the projects success does not rely on these Could Haves - Can easily be left out without impacting on the project o Won't Have - This time round can be left out this time and done at a later date

21. Agile Planning and Planning 21 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Imagine… ► You are fed up with software ► And you decide go into professional house-painting business ► Your first job: Paint the Exterior of This House How do we estimate how long this would take??

22. Agile Planning and Planning 22 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved How might you estimate this? ► One way:  Estimate the exterior surface size  Begin painting  After an hour, see how much has been painted  Extrapolate the total duration I think that’s approximately 2,500² ft After an hour I’ve painted 250² ft So, I should be done in a total of 10 hours I think that’s approximately 2,500² ft After an hour I’ve painted 250² ft So, I should be done in a total of 10 hours

23. Agile Planning and Planning 23 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Estimate Size – Derive Duration Size Velocity Calculation Duration 250 pounds Velocity = 50 Pounds 250/50 = 5 trips 120 story points Velocity = 20 Points 120/20 = 6 Iterations

24. Agile Planning and Planning 24 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Sizing Release/Product Backlog Iteration 1 As an investor, I want to… 3 5 Iteration 2 As an investor, I want to… 5 As a visitor I want to… 1 As an investor, I want to… 2 Iteration 3 As a visitor I want to… 3 3 An investor I want to… 2 Product Backlog (Stories) Define test cases4 Code UI8 Code middle tier12 Code stored procedures12 Automate tests6 Iteration Backlog (Tasks) Story Points or Ideal Days Hours We are talking about these right now

25. Agile Planning and Planning 25 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Measures of Size ► Traditional Measures of Size  Lines of Code  Function Points ► Agile Measures of Size  Ideal Time  Story Points ► Traditional and Agile measure size differently “If you tell people where to go, but not how to get there, you’ll be amazed at the results.” -General George S. Patton “If you tell people where to go, but not how to get there, you’ll be amazed at the results.” -General George S. Patton

26. Agile Planning and Planning 26 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Ideal Time ► How long would something take if:  It’s all you worked on  You had no interruptions  Everything you need is readily available ► The Ideal time of a football game is 60 Minutes  4 x 15-minute quarters ► The elapsed time is much longer (3+ hours) ► Shortcomings of sizing with Ideal Time  My ideal days cannot be added to your ideal days  Ideal days are often confusing and misleading because they do not represent duration  Ideal Time is dependent on the implementer

27. Agile Planning and Planning 27 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Elapsed time vs. ideal time Ideally Monday has 8 hours Each week has 40 hours Monday has 8 hours Each week has 40 hours Instead Monday has: 3 hours of meetings 1 hour of email 4 hours left for project Monday has: 3 hours of meetings 1 hour of email 4 hours left for project This developer will only make 4 hours of progress on Monday It will take two calendar days to complete one ideal day of work This developer will only make 4 hours of progress on Monday It will take two calendar days to complete one ideal day of work “How long will this take?”  Are you answering what is being asked? “How long will this take?”  Are you answering what is being asked? Source: Mike Cohn, Agile Planning and Planning

28. Agile Planning and Planning 28 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Story Points ► The “bigness” of a task ► Influenced by:  How hard it is  How much of it there is ► Relative values are what is important  A login screen is a 2  A search feature is an 8 ► Points are unit-less As a user, I want to be able to have some but not all items in my cart gift wrapped 5 5 Source: Mike Cohn, Agile Planning and Planning

29. Agile Planning and Planning 29 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved More on Story Points ► Approach for starting the sizing process:  Assign 1 to smallest story or Assign 5 to a “medium” story  Size others by comparison/analogy  Alternative: Small-Medium-Large-XL ► Benefits:  Point sizes never decay  Sizes don’t change based on estimator  Are independent of the implementer  Measure of size, not duration  Encourage cross-functional behavior ► Shortcomings:  Can be difficult to get started  Must estimate initial velocity (but you can easily get it after 1 iteration) Problem with T-Shirt Sizing Relative relationship between sizes is lost. Example: How much bigger is a Large than a Medium? Instructor Says: I recommend using Story Points. Most agile projects are using story points. Instructor Says: I recommend using Story Points. Most agile projects are using story points. Source: Mike Cohn, Agile Planning and Planning

30. Agile Planning and Planning 30 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Point Sizing Units ► A 1-point and 2-point story are easily distinguishable  The 2-point story will be twice the size of the 1-point story ► A 17 and 18 story are not very distinguishable  What’s the difference between 17 and 18 anyways? ► Use units that make sense  1, 2, 3, 5, 8  1, 2, 4, 8  Include 0 and ½ if desired Source: Mike Cohn, Agile Planning and Planning

31. Agile Planning and Planning 31 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Exercise: Fruit Points ► Use “Fruit Points” to size the following fruits: watermelon orange blueberry grape strawberry apple grapefruit banana pear peach watermelon orange blueberry grape strawberry apple grapefruit banana pear peach Suggestion Assign 1 to smallest story or Assign 5 to a “medium” story Estimate size of others by comparison/analogy

32. Agile Planning and Planning 32 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Approaches to Sizing ► Estimates are made by a GROUP not an INDIVIDUAL ► Use a consistent relative scale ► Combine techniques  Expert Opinion  Analogy  Disaggregation or Decomposition  Planning Poker Source: Mike Cohn, Agile Planning and Planning

33. Agile Planning and Planning 33 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Estimate by Analogy ► Comparing an un-sized story to previously sized stories  “This story is like Story 5, so it has the same number of points” ► Triangulate  Compare the story to multiple previously sizes stories – not just one  “This story is the same size as Story A and Story B. Both A and B are 5 points, so this story is also 5 points” Story A Story B Story E Story C Story D Story F 3 pts 5 pts 8 pts Source: Mike Cohn, Agile Planning and Planning

34. Agile Planning and Planning 34 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Consider these two

35. Agile Planning and Planning 35 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Disaggregation/Decomposition ► Breaking big stories into smaller stories ► Goal is to define stories that can fit into single iterations ► Don’t spend too much time  A little effort helps a lot  A lot of effort only helps only a little more Effort Accuracy 100 50 At some point, extra effort decomposing actually reduces accuracy (See Critical Chain Project Management reference) Source: Mike Cohn, Agile Planning and Planning

36. Agile Planning and Planning 36 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Planning Poker ► What is it?  It is a tool to facilitate group sizing ► What do you need?  Entire team – including product owner/customer  Deck of planning poker cards with point sizes  Stories

37. Agile Planning and Planning 37 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Planning Poker – How to Play? 1. Each team member is given a deck of cards – each card has a point size written on it 2. Customer/Product-Owner reads a story ► Customer must be knowledgeable enough to discuss each story 3. The story is briefly discussed, questions answered etc. ► The discussion should be sufficient to determine the complexity and relative size of the work 4. Compare story to other, previously sized stories ► Use analogy and triangulation techniques 5. Each team member secretly selects a card that is his or her estimate ► Sizes should be presented together 6. Cards are presented to the group at the same time ► Each person’s opinion is represented 7. Differences and outliers are discussed ► Discuss why some people think a story is bigger than what other people think 8. Re-estimate until estimates converge ► Sometimes the exercise needs to be time-boxed ► Sometimes some negotiation is needed – “Meet the size half-way” 9. If 1 person is a holdout, but is very close  Ask them if the consensus is agreeable Source: Mike Cohn, Agile Planning and Planning

38. Agile Planning and Planning 38 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Planning Poker – an example: As a user, I want to be able to have some but not all items in my cart gift wrapped Round 1Round 2 Jill35 Bob85 Yang25 Ann58 Todd55 Result: Story Size = 5 Points

39. Agile Planning and Planning 39 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Exercise: Remodeling my Kitchen In groups: Size in “Kitchen Points” using planning poker the following stories: ► Install new hardwood floor ► Refinish (remove, sand, repaint) the cabinets ► Replace my tile countertop with granite ► Repaint entire kitchen ► Lay shelf paper ► Install recessed lighting ► Replace electric stove with gas stove ► Install a new oven ► Plumb the island and add sink Source: Mike Cohn, Agile Planning and Planning

40. Agile Planning and Planning 40 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Why Planning Poker Works? ► Emphasizes relative estimating ► Focuses most estimates with an approximate one order or magnitude ► Everyone’s opinion is heard ► Estimators are required to justify sizes ► It’s quick ► It’s fun Source: Mike Cohn, Agile Planning and Planning

41. Agile Planning and Planning 41 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Velocity – a quick reminder ► The rate of work completion ► The amount of sized work completed in an iteration ► The number of points per iteration

42. Agile Planning and Planning 42 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Release Planning Product Backlog Release Planning Workshop Iteration 1 Iteration 2 Iterations 3-6 Release Plan Source: Mike Cohn, Agile Planning and Planning

43. Agile Planning and Planning 43 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Story C Story G Example (Velocity = 21 Points) Story A 5 Story B 3 Story D 8 Story S 5 Iteration 1 Iteration 2 8 Story H 8 5 Iteration 3-6 Story E 5 Story I 2 Story J 1 Story L 13 Story F 13 Story M 8 Story P 5 Story Q 8 Story K 5 Story O 13 Story N 8 Story R 3 Source: Mike Cohn, Agile Planning and Planning

44. Agile Planning and Planning 44 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Updating the Release Plan ► Revisit the release plan at the end of every iteration  Agile planning is continuous and adaptive ► Update plan based on:  Current understanding of velocity  Current prioritization of backlog ► Should take little time – but highly effective

45. Agile Planning and Planning 45 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Release Plan Updating Example Story A 5 Story C 5 Story G 3 Story D 3 Story K 5 Story B 5 Story E 3 Story F 3 Story J 2 Story H 5 Story I 5 Story L 3 Initial Release Plan forecasted an iteration velocity of 16 points. The Release schedule allows for 3 iterations. At Velocity of 16, the forecasted story points to be delivered by the release is approximately 48. During Iteration 1, on 13 points were completed. Therefore, the release plan can be updated to reflect the new velocity. Iteration 1 Iteration 2 Iteration 3 Story A5 Story C5 Story G3 Story D3 Story K5 Story B5 Story E3 Story F3 Story J2 Story H5 Story I5 Story L3 Iteration 1 Iteration 2 Iteration 3 √ √ √ With a lower iteration velocity, fewer stories are now planned for – however, as these are prioritized lower on the backlog – they offer the least value Source: Mike Cohn, Agile Planning and Planning

46. Agile Planning and Planning 46 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Multiple views of Velocity Last Iteration = 36 Mean = 31 Mean (worst 3) = 29 Worst = 25 Iteration Velocity (points) Source: Mike Cohn, Agile Planning and Planning

47. Agile Planning and Planning 47 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Extrapolate Release Scope from Velocity At our slowest velocity we’ll finish here At our current velocity we’ll finish here At our long-term average velocity we’ll finish here

48. Agile Planning and Planning 48 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Here are the results of the last 8 iterations. There are 6 iterations left. Using this data, update the release plan by drawing 3 arrows into it Running TotalPointsStory 55Story A 105Story G 2313Story D 318Story K 5120Story B 598Story E 645Story F 728Story J 775Story H 858Story I 905Story L 933Story M Exercise: Update the Release Plan Last Iteration = Long-term average = 15 Mean of worst 3 = 1414 * 6 = 84 15 * 6 = 90 1010 * 6 = 60 Last Average Worst 3

49. Agile Planning and Planning 49 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved A Final Notes on Story Points and Velocity ► Story points are specific to a team and product ► Points from one team’s backlog cannot be compared to another team’s backlog – comparing Apples to Oranges ► Velocity is dependent on points and therefore cannot be compared across teams “If you want a guarantee, buy a toaster.” – Clint Eastwood in The Rookie “If you want a guarantee, buy a toaster.” – Clint Eastwood in The Rookie

50. Agile Planning and Planning 50 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Iteration Planning Iteration 1 As an investor, I want to… 3 5 Iteration 2 As an investor, I want to… 5 As a visitor I want to… 1 As an investor, I want to… 2 Iteration 3 As a visitor I want to… 3 3 An investor I want to… 2 Product Backlog (Stories) Define test cases4 Code UI8 Code middle tier12 Code stored procedures12 Automate tests6 Iteration Backlog (Tasks) We are talking about these right now

51. Agile Planning and Planning 51 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved 2 Approaches to Iteration Planning ► Commitment-driven iteration planning  “How much are we, as a team, willing to commit to?” ► Velocity-driven iteration planning  “We finished 20 story points last time, let’s plan on 15 story points this time”

52. Agile Planning and Planning 52 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Commitment-driven Iteration Planning ► Discuss the highest priority item on the product backlog ► Decompose it into tasks ► Estimate each task (in hours) ► Ask: “Can we commit to this?”  If yes, see if another backlog item can be added  If not, remove this item but see if we can add another smaller one ► Shortcomings of Commitment-Driven Iteration Planning  Cannot perform longer-term planning  Risk of Parkinson’s Law

53. Agile Planning and Planning 53 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Velocity-driven Iteration Planning Adjust Priorities Determine Target Velocity Do in any sequence Estimate Tasks (in hours) Identify Tasks Select Stories It is sometimes helpful to determine an objective for the iteration “At the end of the iteration I want to show…” Do not try to have the total estimated hours equal to the iteration capacity.

54. Agile Planning and Planning 54 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved Agile Planning Lifecycle Summary Budget Schedule Scrum/Stand-up Product Increment Velocity

55. Agile Planning and Planning 55 ____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____ Click to edit Master text styles Second level Third level Fourth level Fifth level (c) 2007 Copyright BigVisible Solutions. All Rights Reserved References This presentation is based on the book “Agile Planning and Planning” by Mike Cohn- this book is highly recommended for anyone who intends to do estimation and planning on agile projects. Other References Used in this Deck: ► “Agile Planning and Planning” – Mike Cohn. Presentation/Training Material ► “Planning and Tracking on Agile Projects” – Mike Cohn. Presentation Material ► “Estimation Games” – Rob Thomsett. An article about common bad estimation games and antipatterns (http://www.thomsett.com.au/main/articles/hot/games.htm)http://www.thomsett.com.au/main/articles/hot/games.htm