Release sprints

To get our code to production what is left to do is to turn the "potentially" releasable product into a releasable product. To do this a number of activities are required: Which ones and how much effort they require varies greatly between types of organisation.

The fastest way to perform rollout activities is to do them within the development team and to automate as much of the process as possible. While I envy and respect teams that are mature in terms of test and deployment automation and operate in an organisational context that allows them to easily move code from environment to environment I find that this is very often not possible within larger organisations.

Often, among other activities, someone outside the team has to be instructed as to how to deploy code, other parts of the organisation have to be informed about the changes (eg. end users, operations and maintenance teams, etc), and manual regression testing has to be performed.

For the kind of large organisations Mike Cohn refers to in his description of a bank with COBOL code and no automated regression testing or large organisations new to Scrum and Agile I, too, find this is best done within a so-called release sprint.

What is in the release sprint?

Projects I have worked on and organisations I have coached usually included two types of work in their release sprints:

• Work that couldn’t be performed every sprint because it was too time-consuming and/or expensive (e.g stress testing, full regression testing, getting copy text translated)


• Work that is only needed when releasing to production (e.g. bundle software, send out release notes to ops team, send comms package to change management, move code through various environments)

What is a successful release sprint like?

The following was common for successful release sprints across all projects and organisations:

• Independent of how much functionality we had developed and how "big" the release was the release sprint was always the same length (e.g. always 2 weeks).


• Everyone on the team had a 100% focus on getting the release out of the door.


• We never developed any new functionality during the release sprint.


• Although sometimes unpredictable we made use of the task board and tracked our work with a burn-down.

• Sometimes, on larger teams (8-9 people), we were only a subset of the original development team but most of the team stayed on to help. (People who didn't work on the project did other work for the organisation such as e.g. R&D, "business planning", etc but that was not a project issue)

What are your experiences?