Scrum Institute, Scrum Framework Episode #16

Scrum Institute, Scrum Framework Episode #16 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is A Scrum Release Plan? This Might Surprise You! The goal of a release plan is to visualize highlevel planning for multiple Sprints, usually between three to twelve Sprints, or so-called Product Increments. A release plan becomes the guideline that reflects expectations from a Scrum Team about: Which features will be implemented, In what order and when these features will be implemented. The release plan also serves as a benchmark to monitor and control the progress of a project. A release plan serves as a target for actual deployments of software in IT production systems in two ways: Deployment of “Milestone Deliveries” to create business value for the client before the project is complete. These Milestone Deliveries cover a subset of client requirements agreed by the Scrum Product Owner, client, and business stakeholders,Deployment of Final Delivery, which includes all known demands and feature requests from the client and business stakeholders. Before a release plan is created, the following artifacts and information need to be taken into account: A prioritized and estimated Scrum Product Backlog,The measured velocity of the Scrum Team (The velocity is estimated, or its value should be extrapolated from the past similar projects if the Scrum Team is just forming),Success criteria imposed by clients such as schedule, scope, provided human resources allowed by the project budget). Since a Release Plan is heavily associated with the Product Backlog, the Scrum Product Owner governs and maintains the Release Plans. Depending on the demands and priorities of the clients, a release plan is created to satisfy one of these three goals: Feature-Based Release Planning/li>Date-Based Release PlanningFeature-Based and Date-Based Release Planning (The Most Typical) Feature-Based Release Planning What we know: Velocity of the Scrum Team, Features we want to deliver.What we don’t know: How long do we need to deliver these features? For Feature-Based Release Plans, the sum of user story points of requested features within a release is divided by the team velocity. That is going to reveal the number of Sprints required to complete a Milestone Delivery or Final Delivery of the product. And we make the release plan accordingly. Date-Based Release Planning What we know: Velocity of the Scrum Team, The Date we want to deliver.What we don’t know: What features can we deliver until the deadline? For Date-Based Release Plans, we multiply the team velocity by the number of Sprints we have until the release date. That is going to reveal the estimated total number of user story points the Scrum Team can deliver until the release date. And we make the release plan accordingly. Feature-Based and Date-Based Release Planning What we know: Velocity of the Scrum Team, Features we want to deliver, The Date we want to deliver these features.What we don’t know: Can the Scrum Team deliver the requested features until the given deadline? We multiply the team velocity by the number of Sprints we have until the release date. That is going to reveal the estimated total number of user story points the Scrum Team can deliver until the release date. If this number is larger than the sum of user story points of features within a release, then we’re safe. Otherwise, the velocity of the Scrum Team needs to be extended by adding extra human resources