Following on the series of Agile and the last article, Overview of Sprint Retrospective.

Agile project management works on the basis of continuous improvement. To facilitate this, projects are broken down into individual sprints, rather than having one regimented project plan.

The aim of Agile Sprint Release Planning is to identify which product backlog items the team will work on during the forthcoming sprint and to discuss a plan for completing them.

Who is involved in agile release planning?

The entire project team are involved in sprint release planning. This includes:

  • The Product Owner, who will identify the product backlog items, their priorities and propose a sprint goal.
  • The Scrum Master, responsible for facilitating effective discussion and ensuring that the whole team agrees the sprint goal and product backlog items.
  • The Team, who will forecast how many product backlog items they can complete during the sprint and how they will be delivered.

Creating the release plan

Before creating the release plan, the following must be available:

  • A scrum product backlog, which has been prioritised and estimated.
  • How much work the scrum team can complete per iteration (velocity).
  • The agreed goals for the scope, schedule and resources.

The release plan can be created in two ways, depending whether the project is feature-driven or date-driven.


The number of sprints needed to complete the release is determined by using the sum of all features divided by the expected velocity of the scrum team.


To find out how much work can be completed within a given time-frame, the velocity of the scrum team is multiplied by the number of sprints.

Structuring the sprint plan

A typical sprint plan is split into two parts.


Here, the team identify which items from the prioritised product backlog list they will work on during the sprint. Areas discussed during this first part of the meeting include:

  • The sprint goal, which is used to decide which product backlog items are ready, and will be included in the sprint.
  • Which members of the team are available for the sprint, taking into account holidays and other commitments?
  • Which items will be included on the sprint backlog, based on the team’s availability and the sprint goal?
  • How confident the team feel in being able to meet the sprint goal.


Once the scope has been decided, it is time to plan.

The team will discuss, in detail, how the product backlog items will be delivered. Tasks for the product backlog items may be discussed, in addition to any dependencies between the items.

This stage also identifies the items, which each team member will work on.


The main benefit of sprint release planning is that it offers a structured plan, whilst remaining true to the agile principles of flexibility and continuous improvement.

It creates a shared understanding between the team of what product backlog items they will work on, how they contribute to the sprint goal, and which individual tasks have been assigned to each team member.

Common problems

If the team does not have a defined product backlog from which to draw items, it is likely that sprint release planning will be ineffective as time will be spent better understanding the items rather than planning.

Another common pitfall is the failure to establish a specific sprint goal. This results in the team potentially working on unrelated items, meaning that a sprints worth of work can be completed without making progress.  As is the norm in Agile, the sprint release plan isn’t a static document. It will change and be re-estimated throughout the project as new knowledge emerges. It is vital therefore, that the plan is reviewed after each sprint.