Initial Release Plan
The Product Backlog lists all the functionality that the product or solution could have in it. If all of this functionality is built before a release to production it may waste the opportunity that Scrum provides for seeing an early return on investment and useful production feedback. For these reasons it is common practice to divide the Product Backlog into "Releases" or collections of useful system capability that make sense when put into production.
It is important to remember that what looks like a sensible set of releases up front is likely to change over time so some flexibility should be expected. Some common reasons to change a release plan:
- Unforeseen business opportunities
- Sprint Review session where the user group recognise that the demonstrated functionality could immediately provide business value if it were put in to production.
- Too many features for a given release in a given time - requiring more time or less features for the release.
When putting together a release plan, the:
- Business determines when a release is needed, the functionality it must contain, and the acceptable level of quality and cost.
- Development determines how long it takes to build the release
- Development creates preliminary estimates
- Development refines the estimates as priority increases
- Team selects the product backlog for development, each Sprint
- Business focuses on business value derived from the release
