I mentioned in my last blog that my last sprint forced a lot of organization’s and the team’s own unreadiness up to the surface when I tried to release that product. After some more conversation with various folks, I have concluded that a release sprint is a very important concept to have when you have an agile team that’s embedded in a non-agile environment.

This release sprint allows the external parties to “sync up” with your progress. This is also the time when the agile team can focus on working with the external parties to resolve any rollout concerns. This is even more useful when you have an external department that does an additional level of acceptance testing over what you would within the agile team.

The sprint review right before this release sprint is crucial in identifying any external dependencies that are missing. Because the truth is, unless something is close to being released, most people outside the team won’t pay close attention to it.

It’s important to note that this is not a fallback to the waterfall model, since design, development and testing still happen at the same time in the regular sprints. In this special release sprint, the team should not have any stories related to development scheduled other than those identified as critical in the sprint review meeting. Its entire focus should be on the release of the product (addressing external acceptance issues, polishing documentation, training operational personnel, clean up of branches etc).

So before your next official release, plan to have a short release sprint, and right before that release sprint, make sure you sit everyone down in the sprint review meeting to ensure that your team is synced up with the non-agile portion of your organization. It can really serve as an opportunity to kick things off into high gears.