The Release Planning Ceremony

Agile release planning is best accomplished via the straightforward method of getting everyone into a room together. Everybody who will be involved in the release should participate in the planning. That gives us a potential invite list that looks like this:
·         Scrum Master
·         Product Owner
·         Delivery Team
·         Stakeholders
·         Outside experts
·         Customer(s)
·         3rd Party Vendors
·         Marketing
·         Sales
When all of these people gather and work together on the release, marvelous things can happen.
A Release Planning agenda might look like this:
·         Goals of the release (PO)
·         Background, business and competitive climate (PO)
·         Current product and development state (PO)
·         Grooming of Product Backlog for release (All)
·         Capture and discussion of issues (All)
·         Technical Issues  (Dev teams)
o    Technology
o    Testing Challenges and Strategies
o    Dependencies
o    Engineering Standards and Practices
o    Hardening and Hackathon
o    Development regimen
§  Build
§  Test
§  Continuous integration
·         Team interactions (Dev teams)
o    Scrum of Scrums
o    Special handling of multi-team Sprint Planning, Sprint Reviews
o    Multi-team retrospectives
·         Tentative schedule (PO)
Finally, here are a few tips to make your release planning activities effective:
·         Do as little planning as is necessary.
·         Start release planning when you realize you need it, even if it’s near the end of the release effort.
·         Plan using stickies on the walls. If you must transcribe them into an online tool, do that later, after the meeting.
·         Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen. Release planning is not about committing to a list of features to be released on a certain date.
·         Include vendors and other third parties who are relevant and involved in your release planning meeting.
·         Revisit the release plan after each sprint and update it.
·         Don’t give in to the urge to publish a release plan as a separate document
·         There’s no prescribed timebox for release planning because it will vary with the size of the team and the expected length of the release effort.

Release Planning can take more or less time based on a number of variables including the size of the project team, number of stakeholders, level of agreement on objectives, and experience level of the teams and facilitator.  At first you might spend a half day planning an eight week release for two scrum teams and a few stakeholders. With practice, one hundred well-facilitated and prepared people can plan an 8 week  (4 sprint) release in one day. Such a meeting might include a handful of development teams with their Product Owners and ScrumMasters, some outside customers, stakeholders and more.

Comments

Popular posts from this blog

Scrum Answer to Top 10 Software Project Risks