Detailed release planning

Detailed release planning

After the vision, themes and high-level roadmap for the project has been laid out and the stories have been created, the next step is to create the release plan. Release plan gives an estimate of when functionality will be delivered.

Meeting Attendees-

- Product Owner (PO), scrum master, and the whole team

     - Subject matter experts and key stakeholders

       - Sponsor can join you if they like but they're not required.

This session will probably last an hour or two. We do not want to spend more time than this because in scrum we're focused on doing just enough and doing it just in time. Release planning is usually for the next three to six months.

Inputs for the planning session-

Going into this meeting know the sprint length, prioritized and estimated backlog and real or projected velocity. Releases can be planned by schedule or by functionality. PO and stakeholders will need to decide which method to use for the project. The team should be consulted but the decision is the PO's.

Schedule-driven release plan- Set date and using theme and story priority determine what can be delivered in that window. For example, imagine a velocity of 15 points per sprint and the release date at the end of each quarter. With each sprint of two weeks, every month the team delivers 30 points and 90 points per quarter.

The release plan then is simply the set of highest priority stories equaling 90 points. This method is easy but it has one catch. When the themes are written and roadmaps are built, all the themes are not expected to be completed at the same time.  That means that all the functionality of the theme that makes it valuable may not all be done in that 90 points. There may me 90 points worth of stories to deliver but not much end-user value in those stories.

Functionality based planning- The alternate to this situation is functionality-based release planning. PO and stakeholders can look at your backlog and themes and prioritize. Deliver the ability to login, browse courses and see course details there's value in getting students used to navigating the site even if they can't register or pay yet.

If your stakeholders make that statement, the team knows what value must be delivered in the release. Since the stories are already built the team can group all those stories together and tally up the estimates. With the velocity of 15 points per sprint they can divide the total by 15 and they'll know roughly when they're delivering that release.

Also, always keep in mind that release plan is an estimate about when something will be delivered. Not everything is known. Whichever method is used for release planning it's a living document and needs to be updated at the end of every sprint.

Many teams use their release plan to set goals for every sprint. This helps the team to stay focused on getting to the release. The release plan is a valuable tool that helps the PO and team translate the vision and roadmap into a tactical tool to guide them to each release until the vision is attained. Using this tool can help the team get to valuable releases every time.