Provide a summary of this practice.
Release Planning defines the overall structure of the release as a whole, including goals, iterations and stories.
For general principles of Agile planning, click here.
What is the overall goal or intention of this practice?
Release Planning is used:
What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?
Frequency: 1 per release.
Release Planning should not generally take more than 4-8 hours.
What must have happened or been delivered for this practice to be considered complete?
What pre-conditions must be met before this practice is used?
This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.
|1||Prepare planning meeting.|
|2||Initiate planning meeting.|
|3||Agree release goals.|
|4||Validate release stories.|
|5||Map release iterations.|
|6||Detail initial iterations.|
|7||Validate Release Plan.|
|1||Prepare planning meeting.||Product Owner.||Iteration Leads.|
|2||Initiate planning meeting.||Product Owner.||Iteration Leads.|
|3||Agree release goals.||Product Owner.||Iteration Leads.||Agreed release goals.|
|4||Validate release stories.||Iteration Leads||Product Owner.|
|5||Map release iterations.||Product Owner.||Iteration Leads.||Draft Release Plan.|
|6||Detail initial iterations.||Product Owner.||Iteration Leads.||Preliminary iteration plans.|
|7||Validate Release Plan.||Product Owner.||Iteration Leads.||Finalised Release Plan.||If the release duration is fixed and not all expected features/stories have been included, the Product Owner should validate the items the teams plan to complete.|
Validate the plan:
Issues & risks
What are the key concerns in making a success of this practice?
- The term ‘Release Planning’ should not be understood to mean that release will only happen at the end of the plan.
- Releases may actually take place at many points in the plan and may occur at many levels (e.g., external customers, to a staging area, etc.).
- In this context, ‘release’ is a more of an operational or business unit of activity, to which the release team may respond in a variety of ways.
- Release planning is not a one-off event.
- As the release unfolds, more information is uncovered, the system is better understood, the release will almost certainly change.
- These changes will often demand at least some replanning.
- The Refine Backlog practice usually takes place at least once during each iteration, and will often impact the Release Plan.
- Even while a release is in progress, business needs evolve, opportunities emerge, priorities change.
- So release stakeholders are entitled to revise goals, features and stories and their priorities at any point.
- However, it’s also their responsibility to tell the team about changes in good time.
- Release planning does not take precedence over Iteration Planning.
- The Iteration Plan is closer to real delivery, and should take priority.
- The resulting changes may require management with release stakeholders.
- If the team does not have an established velocity, the estimates for the first few iterations are unlikely to be accurate.
- Ideally you should be able to offer ‘confidence limits’ on how many story points you will be able to deliver in the release as a whole, and even individual iterations.