Comparing Agile Development Sprints and Release Sprints
During a project using agile management methodologies, most work is done during the development sprints. The release sprint — often the last sprint before the project is released — can be very different from a development sprint:
You do not develop any requirements from the product backlog.
Based on the work you need to do, your release sprint may be a different length than your regular development sprints.
The definition of done is different for work completed during a release sprint. In a development sprint, "done" means the completion of working product that fulfills a user story. In a release sprint, the definition is the completion of all tasks required for release.
A release sprint includes tests and approvals that may not be practical to do within a development sprint, such as performance testing, load testing, security testing, focus groups, and legal review.
The table shows a comparison between the parts of a development sprint and a release sprint:
|Element||Used in Development Sprint||Used in Release Sprint|
For a development sprint, your sprint backlog contains user stories and the tasks needed to create each user story. You estimate user stories relatively, with story points.
In a release sprint, you no longer need to put your requirements in the user story format. Instead, you will create only a list of tasks needed for the release. You will not use story points, either; just add the estimated hours each task will take.
Involve stakeholders from outside the scrum team who have tasks associated with releasing the product, like enterprise build managers or other configuration managers.
|Daily activities||In a development sprint, your daily activities focus on creating shippable functionality.||In a release sprint, your daily activities focus on preparing your working product for external release.|
Some organizations use a release sprint review as a go or no-go meeting to authorize launching the product.
A release sprint should not be a parking lot for tasks the development team didn't finish in the development sprints. You may not be surprised to hear that development teams are sometimes tempted to delay tasks until the release sprint. You can avoid this by ensuring that the product owner and the team create a proper definition of done for requirements in development sprints, including testing, integration, and documentation.