Get certified - Transform your world of work today


Managing Releases in a Scrum Framework

15 December 2017

Seeja Jiju
Integral Development Corp

This article presents one way of delivering production-ready code at the end of every sprint. In a scenario in which Scrum Teams are actually feature teams engaged in developing, enhancing, or maintaining products, they do not always accomplish a production-deployable product at the end of every sprint.

Ways to successfully deliver production-deployable code

Instead of highlighting the reasons for unsuccessful sprints, I’ll explain the ways to successfully deliver production-deployable code at the end of every sprint.

Consolidate planning

Backlog refinement is a constant activity. Product owners work on the priority and details of their wish list daily. Consolidated planning can be done for getting an overall organizational priority. This is the meeting in which each product owner presents his or her backlog to business stakeholders and ensures that individual product backlogs are aligned with the organizational goals. The frequency of these meetings can be every quarter, or twice a year. After the consolidated plan is approved, teams begin work on the highest-priority items from this backlog. What teams decide to work on in a sprint becomes the sprint backlog for the Scrum Team.

Define a sprint cadence

Following a regular sprint size is advantageous for teams. Teams get into a rhythm to plan, build, and review at a regular cadence. They have more confidence in the velocity and therefore more accuracy in estimations.

Practice continuous integration

It’s important to use continuous integration tools and apply engineering best practices for development teams, especially when there are multiple Scrum Teams working on different features for the same product. Follow a branching strategy to handle daily code check-ins and merges to the release branch. Control merges to the release branch by defining the release readiness criteria. Only the code that meets this readiness criteria is merged with the release branch.

Define what is ready

Similar to defining the acceptance criteria of a story, you must also define readiness criteria for releasing the story. Acceptance criteria of the story can be extended to include the release readiness criteria. The challenge will be to satisfy all the criteria in the same sprint. The tasks required to build the software will precede the tasks required to package and release it. If they are combined and done together, I would call this a successful DevOps implementation.

Assess release readiness

At the end of every sprint review, the stories are “done” with development and testing on the daily build. This Done list becomes the backlog for release. The release backlog is reviewed and prepared for production deployment in the subsequent sprint. All the tasks required to get the developed stories to the delivery channel and production deployment are completed during the following sprint.


Figure 1: Managing a release within sprints


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.8 (10 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up