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.
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