Release Sprint

When the Product Owner and Stakeholders identify that there is sufficient functionality in the system to provide immediate business value they may choose to put this into production. Typically, a "Release Sprint" will follow that contains all the necessary Sprint Backlog tasks to put the system into production. These tasks shouldn't contain additional functionality but they may include:

• Deploying the code to the Production Environment
• Production data population
• Setting up management and operational systems and processes
• Training and handover for support staff
• Cutover and fallback planning

A Release Sprint should be no longer than the normal project Sprint length, no matter how many Sprints have contributed to the Release. It is good practice to regularly assess whether the system is in a state such that a single normal length Sprint is sufficient to put it into production. If the answer is no, then the team need to improve the quality of the existing code and assess whether their definition of "Done" is sufficiently close to production quality for future work.