The release sprint

I had a conversation this afternoon based upon a process diagram I had put together that contained different sprint types; zero, development and release.  A debate ensued along the lines that test and quality and delivery artefacts should be produced all the time and that at the end of every development sprint there should be a shippable product; not so says I, I say "potentially shippable" product.

Herein lies the crux of the difference; the release sprint is all about taking something "potentially shippable" and making it "shippable" or "shipped".  The backlog items for a release sprint are typically all the tasks to put the code/product into production, so they can include:

• Deployment of the newly coded product into its production envrionment
• Populating the new product with production data from the previous live version
• Training / documentation handover for operational support teams
• Formal QA activities if in a regulated environment (eg FDA / FSA)
• Failover and fallback planning in case of a failed deployment

..however they should specifically not include developing any further functionality.

A rule of thumb is that a release sprint should take no longer than a single iteration of the development sprints that have been played. If this is not enough time then there are sub processes that need further tuning so that played and accepted story work is closer to "shippable" when it is "done".