How is a Product Release conducted in a Scrum Project? Release Management is not a new Concept to anyone who has been involved in Software Development. It is a critical element of Scrum Projects. Scrum Product Releases can be more intricate than a Traditional Product Release. The content of each Release is a Quality-checked portion of the Minimum Viable Product (MVP), that can actually be used by the Stakeholders. Release Planning is Done when a Scrum is being initiated; the Plan is updated as the Project progresses, and Releases are Done according to Plan.

If a Project is very large and has multiple Scrum Teams (Scrum Master, Product Owner and Development Team), the coordination of Releases can be very complex, and may require extra Sprints to get the Release correctly packaged pre-Release. Reliable Release Planning instils Confidence in the Project Stakeholders. If the delivered Product is the outcome they are expecting, and knowing when it is scheduled and what will be delivered per Release increases confidence.

Starting to Plan – the Initiate Process

Release Planning is a major activity in the “Initiate” process. While Release Planning has some Features in common with a Traditional Project Plan, in its preliminary format, it is a rough draft. This is because Scrum expects Changes during the Project. Every time there is a Change introduced to a traditional Project, this will affect the Release schedule. However, the resources and timeline are fixed in Scrum. In Scrum Projects it is the content of the Release that could Change. A Release Planning Meeting is held to produce the Release Schedule. The Product Owner is the Release Schedule Owner.

“Conduct Release Planning”- the Activity

The Release Planning Meeting is unusual because it has a really broad audience. A few of the attendees who might be needed are:-.

• A representative of the hardware vendor if brand-new hardware is part of the Project.
• A representative of the Software vendor if required.
• Marketing resources, so that they can Plan the Product launch campaign.
• Sales resources, so that they knowledgeable about the brand-new Product and when it will be provided.
• The Scrum Team and Stakeholders will make up the remainder of the Meeting participants.

The Product Epics are written prior to the release planning meeting. The Epics are loaded into the Product Backlog and prioritized. These Epics are used to Plan the Release. While the fine detail of the Product is unpredictable at this point, it should be possible to specify when Releases ought to occur, and if there is to be more than one Release (i.e at the end of each Sprint). The content of the Release is not important, only the frequency (remember, the very first Sprint Planning Meeting has not been held at this stage, so the Deliverables from the Sprint are still unknown).

The output from this Meeting is the Release Planning Schedule. This schedule must be Reviewed whenever there is a Change to the Product Backlog. This is done either by the addition or deletion of a User Story or via reprioritization of the User Stories.

Product Release – Plan and Estimate Process.

When a Sprint Planning Meeting is held, the Team commits to a set of User Stories that are loaded to the Sprint Backlog from the Product Backlog. If a Release is expected at the end of the Sprint, the Product Features that are Developed during the Sprint will comprise the Release. At this stage, if desired, the Release Planning Schedule can be Refined to show what Features must be in the Release. This is by no means mandatory, and some practitioners advise against specifying Features in the schedule.

Product Release – Implement Process.

One of the activities throughout the Implementation process is “Prioritising the Product Backlog”. Any Change to the Product Backlog could affect the Release, so it is a good time to Review the Schedule when prioritising the Backlog. As Changes are deferred until the next Sprint, the impact will be reprioritization of the Product Backlog.

Product Release – Sprint Review and Retrospective.

Where a Project is extremely complex or large, and has numerous Scrum Teams, it might be decided that a dedicated Sprint is needed to collaborate and build the Release. The Release schedule needs to be updated to accommodate this dedicated Sprint. By this point, we are pretty confident about what is to be Released, so defining Features is not as Risky as it would be before this Sprint. There will also be a Sprint Review and Retrospective for this dedicated Release Sprint.

We found these books great for finding out more information on Agile Scrum:

Product Release – Release.

Throughout the “Release” process, part or all of the MVP is provided to the Stakeholders. This is a Working part of the Application, and could even be readily available to the Company’s target Market, not just internal Stakeholders. There needs to be acceptance of the Deliverable by the crucial Stakeholders, and this might be represented by signing off the Release in the Release Schedule.

Next Iteration – Accept Changes.

If any Changes were needed, they are require to be vetted as to whether they are vital to the MVP or not. If they are accepted, they need to be included in the Product Backlog and prioritized. Generally, such Changes are high priority (or they would have been rejected as not vital to the MVP) and will most likely be included in the next Sprint Backlog. The Change to the Product Backlog is the trigger to revisiting the Release Planning Schedule. The most appropriate time to do this would be once the Development Team has committed to the next Sprint Backlog in the Sprint Planning Meeting.

Variations on a Theme.

The need to preserve the Release Schedule can be simpler than this. This is especially the case where there is only one Release, or on Release every 2 or 3 Sprints. It can likewise be a lot more complex in the case of a large Project, where there are many Teams each Developing Features. In this case there will need to be a Programme or Portfolio Release Schedule, which is Managed by the Program and/or Portfolio Product Owner.

Releasing a Product, or part of a Product, into Production is always a high-Risk situation. The Team should be confident that the Deliverable is of the desired Quality and standard. The product should be as free from defects as possible. Even though it has been tested and approved, it might be advisable to Release as a pilot to a selected Customer group. This is especially the case if the MVP is for Release into the Market, for instance, as a banking mobile app.