What is Release Management and how does it apply to Scrum Projects? Release Management is a vital element of Scrum Projects. In Scrum Projects it can be more complex than Traditional Product Release. This is because the Releases are Done as early and as frequently as possible in Scrum. If a Project is extremely large and has several Scrum Teams, the coordination of Releases can be very complicated. It may need 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, they can see the product forming. Understanding when the release is scheduled and what will be provided also provides Stakeholder confidence.

Release Management: Starting to Plan

Release Planning is a major activity in the “Initiate” process. While Release Planning has some Features in common with a Traditional Project Plan, it is only a rough draft. A Release Planning Meeting is held to produce the Release Schedule. The resources and timeline will not Change. These are fixed in Scrum, but the content of the Release could Change. A Release Planning Meeting is held to produce the Release Schedule. The Product Owner (Voice of the Customer) is the Release Schedule Owner.

Release Management: “Conduct Release Planning”

The Release Planning Meeting is unusual because it has a very broad audience. Some of the attendees who might be required are:-.

• A representative of the hardware vendor if new hardware is part of the Project.
• A representative of a Software vendor if required.
• Marketing resources, so that they can Plan the Product launch campaign.
• Sales resources, so that they are familiar with the new Product and when it will be delivered.
• The Scrum Team and Stakeholders will make up the remainder of the Meeting attendees.

The Product Epics have already been written prior to this and have been entered into the Product Backlog and prioritized. These Epics are utilized to Plan the Release. The fine detail of the Product is uncertain at this point. It should however be possible to define when Releases should occur. They should also determine if there is to be more than one Release, for instance, at the end of each Sprint. The content of the Release is not important, only the frequency. Remember, the first Sprint Planning Meeting has not been held at this stage. At this point the Deliverables from the Sprint are still unknown.

The output from this Meeting is the Release Planning Schedule. This schedule ought to be Reviewed whenever there is a Change to the Product Backlog. This change could be due to either the addition/deletion of a User Story or reprioritization.

Refining the Plan – the Plan and Estimate Process.

When a Sprint Planning Meeting is held, the Team commits to a set of User Stories. These user stories 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 make up the Release. At this point the Release Planning Schedule can be Refined to indicate what Features ought to be in the Release.

Release Management- The Implementation Process.

Among the activities during the Implement process is “Prioritising the Product Backlog”. Any Change to the Product Backlog might affect the Release. It is therefore an excellent time to Review the Schedule when prioritising the Backlog. Changes are deferred to the next Sprint, these changes will therefore effect the reprioritization.

Release Management: Updating the Plan

Where a Project is complicated or really large, with several Scrum Teams, it may be decided that a dedicated Sprint is required to collaborate and construct the Release. The Release schedule needs to be updated to accommodate the Sprint and define what the Deliverable will be. In this case, we are quite positive about what is to be Released, so specifying Features is not as Risky as it would be before a Sprint.

Agree Release Plan – Release.

During the “Release” process, part or all of the MVP is provided to the Stakeholders. This is a Working part of the Application. It might even be offered to the Company’s target Market, not just internal Stakeholders. There ought to be acceptance of the Deliverable by the Stakeholders. This could be represented by signing off the Release in the Release Schedule. The most appropriate time to do this would be once the Team has committed to the next Sprint Backlog in the Sprint Planning Meeting.

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

Next Iteration – Accept Changes.

Change requests can be introduced with regards to the delivered features during the Sprint Review, or to the processes during the Sprint Retrospective. If any Changes were required, they need to be vetted as to whether they are essential to the MVP or not. If they are accepted, they need to be incorporated into 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 likely be included in the next Sprint Backlog. The Change to the Product Backlog is the trigger for revisiting the Release Planning Schedule. The most appropriate time to do this would be once the Team has committed to the next Sprint Backlog in the Sprint Planning Meeting.

Variations on a Theme.

The need to maintain the Release Schedule can be easier than this, especially where there is just one Release, or a Release every 2 or 3 Sprints. It can be a lot more intricate in the case of a large Project. In this case there will need to be a Programme or Portfolio Release Schedule. This is Managed by the Program and/or Portfolio Product Owner.

Releasing a Product, or part of a Product, into Production is a high-Risk situation. The Team needs to be confident that the Deliverable is of the desired Quality and standard and as devoid of problem as possible. Even though it has been tested and authorized, it might be recommended to Release as a pilot to a selected Customer group, specifically if the MVP is for Release into the Market, for example, as a banking mobile app.