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.

Release planning workshop

2,093 views

Published on

Presentation for agile release planning

Published in: Technology, Business
  • Be the first to comment

Release planning workshop

  1. 1. Release Planning
  2. 2. Rick AustinLeadingAgilerick@leadingagile.com678.743.1616www.leadingagile.comtwitter.com/rickaustinfacebook.com/leadingagilelinkedin.com/in/rickdaustin
  3. 3. What Is A Release Plan?
  4. 4. Release Plan• A communication device• Planning tool• Validates value versus cost• Sets the overall context
  5. 5. Agile Delivery Management Scope Time Cost
  6. 6. Agile Delivery Management Time Cost Scope
  7. 7. Business Goals toReleases• Starting with goals and vision• Epics -> Features -> User Stories• Story maps and MMFs• Estimating and planning
  8. 8. Elaboration / Decomposition High Medium Small Details Level Just In Time Business Rules Story 1 Feature A Acceptance Tests Epic Story 2 Feature A UI Wireframe Story 3 Activity Diagram Tasks Just in Time Requirements Breakdown... More Definition
  9. 9. Release Planning Purpose• Plan a release based upon: – Most important features to be delivered – Capacity of the delivery teams
  10. 10. Release Planning Overview• Participants – Product owners or a product owner team – Architecture – Delivery team (programmers, QA, analysts, etc.)• Logistics – Performed prior to release work beginning – Takes ½ - 2 days depending upon release size, complexity, and number of teams
  11. 11. Release Planning Overview• Inputs – Strategy, vision, goals – Candidate set of features / stories• Outputs – Release Vision – Release Plan – Architectural Approach – Testing Approach
  12. 12. Release Planning Overview• Activities – Business reviews strategy, vision, goals – Features are discussed and analyzed – User stories continue to be identified and estimated – User stories are selected based upon team velocity and responsible buffering – Risks are identified
  13. 13. What Is A Vision?• Describes the problem being solved for a release• Describe a product solution• Provides a list of features delivered in the release• Creates shared understanding of purpose
  14. 14. Vision: Problem Statement The problem of Having to run to the rental store Affects People who want to easily watch movies The impact of which is Wasted time, effort, and cost to travel to a store to pick from a limited A successful solution would selection Allow a user to select movies they want to see and have them shipped to their home with a postage paid return
  15. 15. Vision: Product PositionFor PeopleWho Want to watch movies at homeThe ShipFlix system Is a web-based membership systemThat Allows consumers to queue up movies to watch and to be delivered to their homeUnlike Local DVD rental storesOur product Will automatically ship DVDs to a person’s home allowing them to keep 2 disks out at any time providing pre-paid envelopes so the
  16. 16. Epics and Features• Break the Vision down into: – Epics: High level outcomes needed to accomplish the Vision and – Features: Specific changes needed to deliver the Epics• These can be estimated at a high level to determine the product road-map
  17. 17. Epics collections of features, typically 1-3 months inEpic duration. Epics span releases. Epics can span more than one team. These are the things the market cares about.
  18. 18. Epics collections of features, typically 1-3 months in Epic duration. Epics span releases. Epics can span more than one team. These are the things the market cares about. Features are smaller than epics, typically 2-4 weeks inFeature duration. Features are contained within releases. Ideally, features are contained within a team. These are what the Product Owner Cares about.
  19. 19. Epics collections of features, typically 1-3 months in Epic duration. Epics span releases. Epics can span more than one team. These are the things the market cares about. Features are smaller than epics, typically 2-4 weeks inFeature duration. Features are contained within releases. Ideally, features are contained within a team. These are what the Product Owner Cares about. User Stories are the smallest increment of value, typicallyUser less than a week. User Stories are contained within sprint.Story These are the things Engineering Management Cares about.
  20. 20. For Each Release:• Give it a name or statement that describes the purpose• Describe the benefits and goals for the business• Describe the benefits or value the users get Release 1: Two DVDs out to customers Business Value: Begin creating a user base to offer more profitable capabilities User Value: Ability to have two
  21. 21. Release Planning• A Release Plan is a roadmap for communicating with project stakeholders• It is created to communicate when there will be releases and what features will be in them• Often takes the form of a Story Map
  22. 22. Release Planning MeetingRelease Planning Inputs• A business value focused goal for the release• A prioritized set of features or user stories – business value ranking• A course estimate for features or stories• Risks associated with features or stories• A date for the release
  23. 23. Release Planning MeetingRelease Planning Process• The delivery team assesses the groomed backlog• Review the sizing, resize if the team doesn’t agree• Split stories into smaller than a sprint sizes (3 – 4 days to complete)• Order the stories into the current release, the following release, and future releases• Prioritize the stories and risks in the current release
  24. 24. Story Mapping• An approach to organizing and prioritizing user stories• Is a tool to help in defining a roadmap
  25. 25. Benefits of Story Mapping• Provides visibility of the workflow across the system• Points out relationships between stories• Helps to spotlight missing stories• Provides a prioritization mechanism• Release planning is improved by focusing on valuable slices
  26. 26. Preparing for Story Mapping• Understand the users/roles using the system• The major activities performed by the users of the system• Arrange activities in the order they are performed• Define stories required to complete activities
  27. 27. Story Map Visual
  28. 28. Buffering• Buffers for both knows and unknowns• Plan for Dark Matter: Stuff we know is out there• Plan for an Iteration 0 if needed – Establish any needed Build, Continuous Integration, Walking Skeleton, Spikes, Developer Environments• Plan for a Hardening Iteration in a complex environment
  29. 29. Sprint 5 Sprint 4 Sprint 3 Sprint 2 Sprint 1 Velocity and Points
  30. 30. Sprint 5 Sprint 4 Sprint 3 Sprint 2 Sprint 1 3 8 7 3 54 8 3 8 2 Velocity and Points
  31. 31. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 3 2 8 8 7 3 4
  32. 32. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 8 8 7 3 4
  33. 33. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 7 3 4
  34. 34. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 Velocity = 15 pts 7 3 4
  35. 35. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 Velocity = 15 pts 7 3 Velocity = 7 pts 4
  36. 36. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 Velocity = 15 pts 7 3 Velocity = 7 pts 4
  37. 37. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 Velocity = 15 pts 7 3 Avg Sprint Velocity = 12 pts Velocity = 7 pts 4
  38. 38. Velocity and PointsSprint 1 3 5 Velocity = 8 ptsSprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 Velocity = 15 pts 7 3 Avg Sprint Velocity = 12 pts Velocity = 7 pts 4 Backlog = 48 pts
  39. 39. Velocity and Points Release Burn Down ChartSprint 1 3 Velocity = 8 pts 50 48 5 38 40Sprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 29 3 25 19 2 13 Velocity = 10 pts 4 8 0 0 0 1 2 3 4 5 8 Velocity = 15 pts 7 3 Avg Sprint Velocity = 12 pts Velocity = 7 pts 4 Backlog = 48 pts
  40. 40. Estimating Initial Velocity• Ask the team the following question: “Which stories do you think you can commit to getting ‘Done’ from this release during the first iteration? Be realistic in your commitment based on your capacity.”• These stories makeup their initial velocity.• You can also do a ‘Mock Planning Meeting’• Example: a team thinks they can get the first 4 stories on the list completed which total 15 points.
  41. 41. Developing the Release PlanAt this point it is possible to determine the time required tocomplete the work. Backlog: 225 points Historic or initial velocity: 25 points per sprint Buffering: 20% Planning Velocity: 20 points Extra Iterations: • 2 extra sprints • Sprint Zero: 1 sprint • Hardening: 1 sprint Iteration length: 2 weeks
  42. 42. Developing the Release PlanAt this point it is possible to determine the time required tocomplete the work. Backlog: 225 points Historic or initial velocity: 25 points per sprint Buffering: 20% Planning Velocity: 20 points Extra Iterations: • 2 extra sprints • Sprint Zero: 1 sprint • Hardening: 1 sprint Iteration length: 2 weeks Roughly we need 32 weeks to get the project done.
  43. 43. Example With Internal Releases (10-15%: Schedule percentages are approximate and will vary by domain, but show typical agile project activity splits) 10 -15% Schedule 80% - 85% Schedule 5% Upfront Close- Planning 0 20 20 20 0 20 20 20 0 20 20 20 0 20 20 20 0 OutIteration 0 Development Iterations Releases Stabilization/ Hardening/Pre-release Iteration Assuming your initial velocity is 20pts/iteration Capacity per release = 60pts without any buffering 32
  44. 44. At the End of Release Planning• We know the purpose of the project• The team is aligned• We have an estimated project backlog• We have a roadmap (we know how many iterations and releases we have)• We know which stories are part of our first release
  45. 45. Create A Release Plan• Review goals, objectives, and architectural description• Plan the first 3 sprints• Log into the system and schedule payment to payee the customer sets up in the system• Validate the user experience and enough of the architecture to reduce technical risks• Team velocity averages 10 points per sprint
  46. 46. Rick AustinLeadingAgilerick@leadingagile.com678.743.1616www.leadingagile.comtwitter.com/rickaustinfacebook.com/leadingagilelinkedin.com/in/rickdaustin

×