Release planning workshop

1,701 views

Published on

Presentation for agile release planning

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,701
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
158
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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
  • Explaining the hierarchy of value\n
  • Explaining the hierarchy of value\n
  • Explaining the hierarchy of value\n
  • \n
  • 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
  • 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
  • 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
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • \n
  • 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
  • Each of these items are now available by the end of release planning. This sets the team up for iteration planning.\n
  • \n
  • \n
  • \n
  • 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

    ×