Scrum Project Release Sprints
Sometimes releasing product features into the marketplace requires completing certain jobs that can’t fit within a normal developmental sprint. Ideally, all activities required to release a product to the market are done within a normal sprint. But if the way an organization is set up does not allow it, a release sprint may be used to accomplish such purposes as
Verifying scaling (for example, load or performance testing)
Broader testing activities (for example, focus groups or validating that developed functionality works with live data)
Simply phrased, a release sprint is for “all that other stuff” that needs doing to get the product to market.
The release sprint is commonly used at the end of the normal series of sprints within a release. The length of a release sprint may be a different length than the development sprints in the release. The release sprint length depends on the types of activities and the amount of work required to release the completed product increments from each sprint. The scrum team determines all these factors during release planning.
During a release sprint, no actual development of requirements is done. All development tasks (such as testing, technical documentation, quality assurance, and peer review) are completed during each sprint to satisfy the team’s definition of done, which in turn ensures potentially shippable product at the end of each sprint. But before it can actually go out to the market, other things (such as focus groups or load and performance testing) may need to be done.
Because the release sprint length and activities are often different than the development sprints, no concept of velocity exists for a release sprint. Development teams estimate to the best of their knowledge the effort and complexity of the tasks for the release sprint. They should all agree and feel comfortable with the release sprint length after it is decided.
The release sprint is a form of antipattern in organizations that cannot do scaling testing and organizational support tasks within the sprint. If you don’t need it, don’t do it.
Including examples already given, uses for release sprints may include the following:
Conducting focus groups (keep in mind that this is not to identify new features, but to validate what you’ve done and identify release issues)
Tweaking performance based on scaling test results
Integrating the product within enterprise‐wide systems
Creating documentation such as user manuals
Finalizing any regulatory requirements