Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

An introduction to agile estimation and release planning

1,425 views

Published on

A simple introduction to Agile estimation and release planning

Published in: Technology

An introduction to agile estimation and release planning

  1. 1. AN INTRODUCTION TO AGILE ESTIMATION AND RELEASE PLANNING James Whitehead
  2. 2. INTRODUCTION ⦿ Building the product backlog ⦿ Estimation ⦿ DEEP ⦿ Splitting your user stories ⦿ Planning ◼ Release Planning
  3. 3. PRODUCT BACKLOG ⦿ A list of user stories form your Product Backlog. Often termed PBI (Product Backlog Item) As a xxxxx I want xxx so that xxxx As a xxxxx I want xxx so that xxxx As a xxxxx I want xxx so that xxxx As a xxxxx I want xxx so that xxxx As a xxxxx I want xxx so that xxxx As a xxxxx I want xxx so that xxxx
  4. 4. ESTIMATE EACH ITEM How long is this going to take? - 1 day ? - 1 week? - Forever?
  5. 5. ESTIMATE EACH ITEM How long is this going to take? - 1 day ? - 1 week? - Forever? Estimates are not time based but relative to each other
  6. 6. ESTIMATE EACH ITEM ⦿ Is ⦿ likely to take longer than ⦿ ? ⦿ Remember estimation is relative sizing! #1 #2
  7. 7. Why Is estimation so hard?
  8. 8. 2 – ESTIMATE EACH ITEM RELATIVE ESTIMATION Estimating Story Points Using Complexity Buckets   ⦿ This approach provides a consistent way for teams to size stories by discussing each story in terms of pre-defined buckets of complexity before deciding on the final points.   ⦿ The steps are simple: ◼ Decide on the buckets of complexity you think match your project. For example, many software development efforts have the buckets used below. ◼ Discuss the story in each bucket and determine if the team can agree if the work it has a Light, Medium, High or Complex level of complexity. ◼ Add up the points and see which Fibonacci Story Point bucket it falls into. If it falls between two buckets, have the team do a gut check and decide on which ones it falls into.
  9. 9. 2 – ESTIMATION HELPFUL TIPS User Interface Business Logic Data/Integration Testing L = 1 L = 1 L = 1 L = 1 M = 2 M = 2 M = 2 M = 2 H = 3 H = 3 H = 3 H = 3 C = 4 C = 4 C = 4 C = 4 Helpful Considerations Helpful Considerations Helpful Considerations Helpful Considerations - number of screen fields? - number of business rules? - number of data stores - user testing complexity - Screen validation logic? - business rules complexity - complexity of Stored procedures/triggers - data setup complexity for each test pack - number of screens?   - number of tables/relationships - test automation complexity 1 2 3 5 8 13 21 Example As a customer, I want to browse the list of products so that I view the details. User interface: M = 2 Business Logic: N/A Data: L = 1 Testing: L = 1 Total is 4 points, which is between 3 and 5, team decide on 3.
  10. 10. USER INTERFACE ⦿ L = 1 ⦿ M = 2 ⦿ H = 3 ⦿ C = 4 ⦿ Helpful Considerations ◼ - number of screen fields? ◼ - Screen validation logic? ◼ - number of screens?
  11. 11. BUSINESS LOGIC ⦿ L = 1 ⦿ M = 2 ⦿ H = 3 ⦿ C = 4 ⦿ Helpful Considerations ◼ - number of business rules? ◼ - business rules complexity
  12. 12. DATA/INTEGRATION ⦿ L = 1 ⦿ M = 2 ⦿ H = 3 ⦿ C = 4 ⦿ Helpful Considerations ◼ - number of data stores ◼ - complexity of Stored procedures/triggers ◼ - number of tables/relationships
  13. 13. TESTING ⦿ L = 1 ⦿ M = 2 ⦿ H = 3 ⦿ C = 4 ⦿ Helpful Considerations ◼ - user testing complexity ◼ - data setup complexity for each test pack ◼ - test automation complexity
  14. 14. EXAMPLE As a customer, I want to browse the list of products so that I can view the details. User interface: M = 2 Business Logic: N/A Data: L = 1 Testing: L = 1 Total is 4 points, which is between 3 and 5, team decide on 3 because the business logic is not applicable.
  15. 15. INVEST Letter Meaning Description I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story. N Negotiable User stories, up until they are part of a sprint, can always be changed and rewritten. V Valuable A user story must deliver value to the business E Estimable You must always be able to estimate the size of a user story. S Sized appropriately or Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. T Testable The user story or its related description must provide the necessary information to make testing of the development possible. The INVEST mnemonic was created by Bill Wake as a reminder of the characteristics of a good quality user story, as may be used in a Scrum backlog.
  16. 16. INDEPENDENT ⦿ The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  17. 17. NEGOTIABLE ⦿ User stories, up until they are part of a sprint, can always be changed and rewritten.
  18. 18. VALUABLE ⦿ A user story must deliver value to the business ◼ Value can be monetary ◼ Gain more customers ◼ Coming up with technical stories that are really fun to code but bring no value to the end-user violates one of the Agile Principles, which is to continuously deliver valuable software to the business.
  19. 19. ESTIMABLE ⦿ You must always be able to estimate the size of a user story. ◼ If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of a sprint. ◼ So there's actually no point in keeping this kind of user story in the Product Backlog at all.
  20. 20. TESTABLE ⦿ The user story or its related description must provide the necessary information to make testing of the development possible. ◼ Remember here these tests can be part of your conditions of satisfaction or acceptance criteria.
  21. 21. SIZED APPROPRIATELY ⦿ User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. ◼ Try to keep your user story sizes to typically a few person-days and at most a few person-weeks. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. ◼ There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a sprint backlog becomes closer
  22. 22. OR SMALL ◼ Try to keep your user story sizes to typically a few person-days and at most a few person- weeks. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. ◼ There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a sprint backlog becomes closer
  23. 23. MY USER STORY IS TOO BIG ⦿ What do you do if the estimation is too big!!
  24. 24. EXAMPLE OF A USER STORY (THIS IS AN EPIC) ⦿ As a Director of Marketing, I want to review the performance of historical advertising campaigns so that I can identify profitable campaigns worth repeating.
  25. 25. INVEST Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story. Negotiable User stories, up until they are part of a sprint, can always be changed and rewritten. Valuable A user story must deliver value to the business Estimable You must always be able to estimate the size of a user story. Sized appropriately or Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. Testable The user story or its related description must provide the necessary information to make test development possible.
  26. 26. INVEST Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story. Negotiable User stories, up until they are part of a sprint, can always be changed and rewritten. Valuable A user story must deliver value to the business Estimable You must always be able to estimate the size of a user story. Sized appropriately or Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. Testable The user story or its related description must provide the necessary information to make test development possible. Has too many dependencies on other stories You could negotiate on parts of the story Clearly there is business value here avoids spending on campaigns and maximises investment in good campaigns Can you really size this properly. This story is very large and not small at all There are so many test here on data and output to get testing into shape is complex and time consuming
  27. 27. EXAMPLE OF A USER STORY (STILL EPICS) ⦿ As a Director of Marketing, I want to select the timeframe to use when reviewing the performance of past advertising campaigns so that I can identify profitable ones. ⦿ As a Director of Marketing, I want to select which type of campaigns (direct mail, TV, e- mail, radio and so on) to include when reviewing the performance of historical advertising campaigns.
  28. 28. EXAMPLE OF A USER STORY (THREE STORIES) ◼ As a Director of Marketing, I want to set simple date ranges to be used when reviewing the performance of past advertising campaigns so that I can pick an exact set of dates. ◼ As a Director of Marketing, I want to select seasons (spring, summer, autumn, winter) to be used when reviewing the performance of past advertising campaigns so that I can view trends across multiple years. ◼ As a Director of Marketing, I want to select a holiday period (Easter, Christmas and so on) to be used when reviewing the performance of past advertising campaigns so that I can look for trends across multiple years.
  29. 29. EXAMPLE OF A USER STORY 3 STORIES OR ARE THEY CONDITIONS OF SATISFACTION (ACCEPTANCE CRITERIA)??? ◼ Set simple date ranges of past advertising performance ◼ Pick an exact set of dates. ◼ Select seasons (spring, summer, autumn, winter) ◼ View trends across multiple years. ◼ Select a holiday period (Easter, Christmas and so on) ◼ Review performance trends across multiple years.
  30. 30. SOME MORE TIPS ON SPLITTING USER STORIES
  31. 31. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 1. Workflow Steps ◼ What steps does a user perform? ◼ Are all steps necessary (right now)? ◼ Can steps be simplified (for now)? ◼ i.e. steps in an order process, like selecting a payment option, delivery method.
  32. 32. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 2. Business Rules ◼ What rules apply to this story ◼ Are all business rules necessary (right now)? ◼ Can simpler rules suffice (for now)? ◼ i.e. failures during webshop order process and possible recovery options maybe done as a later user story.
  33. 33. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 3. Happy/Unhappy flow ◼ What does the happy/unhappy flow look like? ◼ Are all unhappy flows necessary (right now)? ◼ Can unhappy flows be simplified (right now)? ◼ i.e. failures during webshop order process and possible recovery options
  34. 34. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 4. Input options ◼ Which platforms are supported? ◼ Are all platforms required (right now)? ◼ Are some platforms harder than others? ◼ i.e. tablet, iPhone, desktop, touchscreen PC
  35. 35. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 5. Datatypes and parameters ◼ What datatypes are supported? ◼ What parameters are relevant? ◼ i.e. different search options/strategies or different kinds of reports (table, graphs etc)
  36. 36. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 6. Operations ◼ What operations does this story entail? ◼ Are all operations necessary (right now)? ◼ i.e. splitting down CRUD (create, read, update, delete) operations
  37. 37. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 7. Test cases/ acceptance criteria ◼ What tests are used to verify this story? ◼ What acceptance criteria apply? ◼ Are all test scenarios necessary (right now)? ◼ i.e. some test scenarios may be very complex and not highly relevant to the context of this user story.
  38. 38. SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE) ⦿ 8. Roles ◼ What roles are involved in this story? ◼ Are roles necessary now? ◼ i.e. customer can create orders, administration can manager orders, pickers can pick and order, packers can pack and order and shipping can ship the order.
  39. 39. SUMMARY ⦿ Stories will change ⦿ Everyone estimates ⦿ Points are NOT a unit of time but relative ⦿ Being consistent is more important than being accurate ⦿ Estimates must include uncertainty
  40. 40. ACCEPTANCE CRITERIA OR CONDITIONS OF SATISFACTION
  41. 41. GOOD ACCEPTABLE CRITERIA AND TESTS ⦿ S – Specific – Explicitly defined and definite ⦿ M – Measureable – Possible to observe and quantify ⦿ A- Achievable – Capable of existing and taking place ⦿ R – Relevant – Having a connection with the story ⦿ T – Time-bound – When will the outcome be observed
  42. 42. SPECIFY BY EXAMPLE Data Expected Result Expected Message Aa9ab$ Fail Too Short AAbbCC11 Fail No Special Characters $$$bbb111 Fail No Upper Case AAA%% Fail No Lower Case AAAA%%%% bbbbb Fail No numbers IsThis$AGood1 1 Pass
  43. 43. DEEP
  44. 44. DEEP How DEEP is your Product Backlog. The product backlog should have the following key attributes (DEEP): (D)Detailed appropriately (E)Estimated (E)Emergent (P)Prioritized
  45. 45. DETAILED APPROPRIATELY ⦿ User stories that are high priority are described in detail so that they can be well understood before they can be completed in the coming sprint. ⦿ Stories that are on low priority should have “just enough” details and they can be refined over time.
  46. 46. ESTIMATED ⦿ Product backlog also acts as a planning tool other than acting as a work to do repository. ⦿ The items on the backlog are estimated and the estimates for the user stories down the order are usually less precise because all the details are not understood yet. ⦿ They can be refined overtime.
  47. 47. EMERGENT ⦿ The product backlog is not static. It evolves, and its contents change over time. ⦿ As more is learned and discovered, user stories are added to the product backlog. ⦿ Existing user stories are modified, re- prioritized, refined, or removed on a regular basis.
  48. 48. PRIORITIZED ⦿ All items in the product backlog are prioritized. ⦿ Teams select high-priority items from the backlog. If there is no effort estimate, or if it needs review, a new estimate is created. ⦿ The most valuable and highest-priority items are implemented first and the least valuable ones at last. ⦿ This approach of following the priority order helps teams to maximize the value of the product or system being developed for the business (Product Owner).
  49. 49. PRIORITISE 2 6 4 2 4 6 2 4 4
  50. 50. PRIORITISE ⦿ - Apply a Business Value 2 6 4 2 4 6 2 4 4
  51. 51. PRIORITISE ⦿ - Prioritise By Business Value 2 6 4 4 4 6 4 2 2
  52. 52. SUMMARY - PRIORITISE ⦿ It is important for the team to help the Product Owner prioritise and get into the mind of focus on the right things ⦿ It helps the development team focus on doing things right ⦿ Remember the Product Owner has the final word ⦿ Technical dependencies are relevant ⦿ Priorities will change over time
  53. 53. VELOCITY ⦿ What is all this talk about velocity! ⦿ Velocity is the amount of stories completed during a sprint that can then be estimated or planned for future sprints.
  54. 54. SPRINTS – PLANNED VELOCITY 8 10 14 14 14 18 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 2 2 2 2 2 4 2 2 2 2 4 6 4 4 4 2 2 4 6 2 2 4 6 6 What if we don’t have enough history of Agile/Scrum to get the velocity Planned Velocity
  55. 55. 2 10 14 14 14 18 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Velocity SPRINTS
  56. 56. 2 10 14 14 14 18 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Velocity = 12 SPRINTS Velocity is the number of completed stories divided by the planned sprints
  57. 57. SUMMARY ⦿ Planned Velocity is useful only until we have real data - just an educated guess ⦿ “Yesterday’s weather” is more important than average ⦿ Sprints must create production-quality potentially shippable products ⦿ Velocity is specific for a team as each team is unique
  58. 58. 5 – MIN BREAK
  59. 59. PLANNING
  60. 60. PLANNING ⦿ So how do we plan in Agile/Scrum
  61. 61. CANDIDATE SCHEDULE ⦿Say planned velocity is 6
  62. 62. CANDIDATE SCHEDULE ⦿Say planned velocity is 6 ⦿Backlog is 34 points total
  63. 63. CANDIDATE SCHEDULE ⦿34 /6 = 6 Sprints
  64. 64. CANDIDATE SCHEDULE Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 2 4 6 2 4 2 4 6 4
  65. 65. CANDIDATE SCHEDULE ⦿ Remember no more than 6 as this is your velocity! ⦿ (Yes you can negotiate within the team but be careful remember it is a team commitment not you as an individual)
  66. 66. CONCLUSION ⦿ This is just a framework - there are multiple variants ⦿ The Product Owner and Business (Subject Matter Experts) are partners during estimation and planning ⦿ Don’t try to change the world, change your plan
  67. 67. MONITOR AND ADAPT ⦿ You can’t embrace change and have a plan written in stone ⦿ Re-estimate whenever necessary ⦿ Don’t try and force real life to look like your plan - It’s the other way around
  68. 68. MONITOR AND ADAPT
  69. 69. RELEASE PLANNING
  70. 70. MONITOR AND ADAPT ⦿ Plans are nothing. ⦿ Planning is everything. Dwight D. Einsenhower
  71. 71. RELEASE PLANNING – WHERE DOES IT FIT IN AGILE/SCRUM
  72. 72. PLANNING LEVELS Product Backlog Release Backlog Sprint Backlog Might have an initial estimate (perhaps both analysis and development and an expression of technical and business confidence that this is real and achievable As a __, I want to be able to __ so that __ As a __, I want to be able to __ so that __ More detailed estimate and a specific acceptance test – low confidence stories might be spiked or prototyped I will know this is done when _____ As a __, I want to be able to __ so that __ I will know this is done when _____ To do this I must 1) ______ 2) ______ Business Goal Possible automation of the acceptance test Development team breaks out the detail of work needed to pass test
  73. 73. RELEASE PLANNING SCHEDULE Apr May Jun Jul Aug Sep Oct Nov Release Meeting 1 2 3 4 Releases 1 1 2 2 3 3 4 Ideally a release planning meetings happens once every two months to set the PBIs for the following Releases, just so happens we have gone and set them against months above but…..
  74. 74. EXAMPLE RELEASE PLAN Major Features (Themes) Sprint 1 Sprint 2 Sprint 3 Sprint 4 to 6 Quarter 2 Quarter 3 Year 2 Authentication Login Screen   Security Questions   SSO Integration with Partner Sites     SSL Encryption             Order Entry   Product Selection         Sponsored Lookups   Product Review Product Comparison         Checkout   Checkout   Coupons             Order Tracking     Reward Points Release Plans can be set against Sprints And Sprints can be between 1 to 4 Weeks in length.

×