Correct Use of a Release Sprint

In Scrum we tell teams that at the each of each sprint they need to product a "potentially shippable product increment." However, "potentially shippable" and "shippable" are not the same thing. Some large or complex projects will require the use of "release sprint" or "hardening sprint" at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.

A great example is a bank I work with. They have 12,000,000 lines of COBOL code that manages bank balances. They have a 1,000,000 line web application that can write to the same database as the big COBOL application. Manual testing of the COBOL system takes three weeks. The web team targets having a potentially shippable application each sprint. They end each sprint pretty sure that they haven't messed up the COBOL system because they are conscientious developers. However, they don't know that they haven't messed up the COBOL system. And they do know that eventually the odds will catch up with them and given enough sprints they will eventually mess up the COBOL system somehow. So they run a release sprint every few sprints before the website goes live. They do the manual system testing that would be prohibitively expensive to do in each sprint at that time.

Of course we'd all love the COBOL system testing to be an automated single-button click that could be done in each sprint but since that's unrealistic in their situation right now it's done during the release sprint. If you use a release sprint be sure that the length of the release sprint is independent of the number of sprints that precede it. To continue with the team above, if they ran five regular sprints before deciding to ship the web application, they need three weeks for a release sprint. If they ran twenty regular sprints before deciding to ship, they should also need just one three-week release sprint. To say otherwise would be to plan for work (such as bugs) to slop over from one sprint to the next.