Release planning workshop
Download as KEY, PDF•11 likes•3,334 views
The document discusses release planning in an agile environment. It defines what a release plan is and its purpose to communicate the scope and timeline of releases to stakeholders. The process of creating a release plan is described, including identifying epics, features, and user stories to fulfill the release vision, estimating work, and using velocity to determine the timeline and number of iterations needed to complete the planned work.
Release planning workshop
- 3. What Is A Release Plan?
- 4. Release Plan • A communication device • Planning tool • Validates value versus cost • Sets the overall context
- 5. Agile Delivery Management Scope Time Cost
- 6. Agile Delivery Management Time Cost Scope
- 7. Business Goals to Releases • Starting with goals and vision • Epics -> Features -> User Stories • Story maps and MMFs • Estimating and planning
- 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. Release Planning Purpose • Plan a release based upon: – Most important features to be delivered – Capacity of the delivery teams
- 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. Release Planning Overview • Inputs – Strategy, vision, goals – Candidate set of features / stories • Outputs – Release Vision – Release Plan – Architectural Approach – Testing Approach
- 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. 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. 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. Vision: Product Position For People Who Want to watch movies at home The ShipFlix system Is a web-based membership system That Allows consumers to queue up movies to watch and to be delivered to their home Unlike Local DVD rental stores Our 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. 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. 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.
- 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 in Feature duration. Features are contained within releases. Ideally, features are contained within a team. These are what the Product Owner Cares about.
- 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 in Feature 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, typically User less than a week. User Stories are contained within sprint. Story These are the things Engineering Management Cares about.
- 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. 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. Release Planning Meeting Release 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. Release Planning Meeting Release 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. Story Mapping • An approach to organizing and prioritizing user stories • Is a tool to help in defining a roadmap
- 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. 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. Story Map Visual
- 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. Sprint 5 Sprint 4 Sprint 3 Sprint 2 Sprint 1 Velocity and Points
- 30. Sprint 5 Sprint 4 Sprint 3 Sprint 2 Sprint 1 3 8 7 3 5 4 8 3 8 2 Velocity and Points
- 31. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 5 Sprint 4 Sprint 3 Sprint 2 8 3 2 8 8 7 3 4
- 32. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 8 8 7 3 4
- 33. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 5 Sprint 4 Sprint 3 Sprint 2 8 Velocity = 11 pts 3 2 Velocity = 10 pts 8 8 7 3 4
- 34. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 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. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 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. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 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. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 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. Velocity and Points Sprint 1 3 5 Velocity = 8 pts Sprint 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. Velocity and Points Release Burn Down Chart Sprint 1 3 Velocity = 8 pts 50 48 5 38 40 Sprint 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. 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. Developing the Release Plan At this point it is possible to determine the time required to complete 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. Developing the Release Plan At this point it is possible to determine the time required to complete 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. 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 Out Iteration 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. 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. 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
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: Here is a complete breakdown of the hierarchy from Epic to Task\nEPIC/Theme: have all been used to describe a larger piece of requirement that may include multiple features within it. \nEpic is used to describe functionality that is too big to get done within a sprint and needs to be broken down to a smaller chunk.. \nFeature: a medium sized, business understandable description of functionality. You may have some of these on your list as placeholders that you breakdown and estimate when you’re ready to include them in the next release\nStory: Small valuable business requirement that follows the INVEST attributes\n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: The hierarchy of requirements goes:\nEpics – business oriented components of the project vision, then\nFeatures – specific components of epics, but probably still too large to accurately estimate or deliver in an iteration.\n
- #18: Explaining the hierarchy of value\n
- #19: Explaining the hierarchy of value\n
- #20: Explaining the hierarchy of value\n
- #21: \n
- #22: Release planning is the process of deciding when the project will releases and what will be in those releases.\n\nTypically we have more detail about what exactly will be in the next release and less detail about what will be in subsequent releases\nHowever there needs to be a reasonable and defendable plan for completing all the agreed work within the available time otherwise we need to discuss resceduling or de-scoping the project\n
- #23: Inputs into the Release Planning meeting include:\n A business value focused goal for the release – e.g. “the basic movie renting and buying release to get some revenue”\n A prioritized set of user stories – business value ranking – stories that support renting and buying movies\n A course estimate for each story – t-shirt size estimate – with a level of confidence from the team that these look acheivable\n Risks associated with the stories – what might we need to watch out for?\n A date for the release – E.g. May 15th \n\nIt is the team and not the product owner or scrum master that needs to determine what is feasible. \nThe PO sets priority but cannot influence estimates\n
- #24: Inputs into the Release Planning meeting include:\n A business value focused goal for the release – e.g. “the basic movie renting and buying release to get some revenue”\n A prioritized set of user stories – business value ranking – stories that support renting and buying movies\n A course estimate for each story – t-shirt size estimate – with a level of confidence from the team that these look acheivable\n Risks associated with the stories – what might we need to watch out for?\n A date for the release – E.g. May 15th \n\nIt is the team and not the product owner or scrum master that needs to determine what is feasible. \nThe PO sets priority but cannot influence estimates\n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #31: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #32: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #33: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #34: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #35: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #36: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #37: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #38: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #39: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #40: By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
- #41: The team will not know there velocity for the first iteration so it must be based upon the team’s capacity and understanding they must meet the definition of “done” for their stories. Teams are optimistic about their initial velocity and that needs to be considered during this planning. The teams pick those stories they feel confident they can complete and the total of those story points become their initial velocity.\n\nTo gain a better understanding of what they can accomplish a team might go through a mock planning meeting. The team will break down stories into tasks to provide additional confidence that they can commit to the number of story points they have selected.\n
- #42: \n
- #43: Here we see how a project can have one or more releases and a release consists of one or more iterations. \nUpfront we may have an iteration 0 that establishes the development environment and tools. The remainder of the iterations will most likely be for adding functionality and will have associated velocity scores (the “20”s in the image above), but some iterations might be for hardening and stabilization and will not deliver new functionality.\n
- #44: Each of these items are now available by the end of release planning. This sets the team up for iteration planning.\n
- #45: \n
- #46: \n
- #47: \n