Release Planning in Agile

Release Planning in Scrum

organizations that use a Scrum process have a number of Scrum Teams that must collaborate to produce products. Issues that arise in moving to a Multiple-Team context include release

·       How to divide a large organization that use a Scrum process have a number of Scrum Teams that must collaborate to produce products. Issues that arise in moving to a Multiple-Team context include release

·       How to divide a large group of potential Team members into a specific set of Teams

·       How many Scrum Masters are needed to support the Teams

·       How many Product Owners are needed to support the Teams

·       How to develop requirements that span many Teams

·       How to plan, track, and enable successful coordination of work that spans many Teams

·       How to balance the competing needs for Product Management for both customer focus and Team focus

·       How to plan and track work for longer time horizons than one Sprint

·       e group of potential Team members into a specific set of Teams

·       How many Scrum Masters are needed to support the Teams

·       How many Product Owners are needed to support the Teams

·       How to develop requirements that span many Teams

·       How to plan, track, and enable successful coordination of work that spans many Teams

·       How to balance the competing needs for Product Management for both customer focus and Team focus?

·       How to plan and track work for longer time horizons than one Sprint

Release Planning

How the Release Planning in Scrum is different from a Traditional Waterfall Model?

In a Traditional Waterfall Model, once we start the project, three factors are fixed - Time, Cost and Scope. But in Scrum the Scope is evolving as we progress and Product Backlog is updated as and when we get more information. So how the Release Planning can be done in a scenario where the Scope is not fixed?

First let's discuss what Release Planning is in Scrum. Scrum Release Plan is a high level plan for multiple Sprints. It serves as a guideline that reflects how many features will be developed and when those features will be developed. It also serves as a baseline to monitor the progress of the project. Think of it as a roadmap guiding you towards your final destination

In Scrum, before we start Release Planning, we need to have the following items ready.

1.              Prioritized and Estimated Product Backlog.

2.              Estimated Velocity of the Scrum Team - Total number of Story Points done per Sprint.

Product Backlog: Product Backlog is the list of items/features the Product Owner wants the development team to deliver at the end of the Project. Before the start of the first release, the Product Backlog should be ready. The Product Owner and the Team work together on Product Backlog Refinement. This process could take a few days or weeks. This process may involve workshops, detailed requirement analysis and estimation of all the items identified for the release. 

Release Planning

How the Release Planning in Scrum is different from a Traditional Waterfall Model?

In a Traditional Waterfall Model, once we start the project, three factors are fixed - Time, Cost and Scope. But in Scrum the Scope is evolving as we progress and Product Backlog is updated as and when we get more information. So how the Release Planning can be done in a scenario where the Scope is not fixed?

First let's discuss what Release Planning is in Scrum. Scrum Release Plan is a high level plan for multiple Sprints. It serves as a guideline that reflects how many features will be developed and when those features will be developed. It also serves as a baseline to monitor the progress of the project. Think of it as a roadmap guiding you towards your final destination; what exits you will take or what actions you will take while driving will be decided en route.

In Scrum, before we start Release Planning, we need to have the following items ready.

1.              Prioritized and Estimated Product Backlog.

2.              Estimated Velocity of the Scrum Team - Total number of Story Points done per Sprint.

Product Backlog: Product Backlog is the list of items/features the Product Owner wants the development team to deliver at the end of the Project. Before the start of the first release, the Product Backlog should be ready. The Product Owner and the Team work together on Product Backlog Refinement. This process could take a few days or weeks. This process may involve workshops, detailed requirement analysis and estimation of all the items identified for the release. 

Estimated Velocity of Scrum Team: 
There are two methods the Velocity can be calculated.

1.              Velocity based on Historical Data

2.              Velocity Estimation with no Historical Data

Velocity based on Historical Data:
The Following graph represents the historical data of multiple Sprints. Based on this data we get Avg. Velocity (Vavg), Maximum Velocity (Vmax) and Minimum Velocity (Vmin) of a Team. 

Velocity Estimation with no Historical Data:
When there is no historical data then the Velocity can be calculated by using the following method.

Based on the team size and availability, calculate the capacity of team. (e.g. 300 Hours)

1.              Select high priority user story from the product backlog

2.              Breakdown the user story into tasks.

3.              Estimate the tasks in terms of hours.

4.              Add the hours of all the tasks of user story.

5.              Now check if there is more capacity for a Sprint. 

6.              If yes, then repeat the same exercise for the next user stories till you are full with your team’s capacity.

7.              Add the total Story Points of User Stories selected for this Sprint.

8.              This will give you the velocity for the first Sprint.

Once you have your prioritized Product Backlog and an estimated Velocity, you can start working on release planning.

Release Planning:

As mentioned above, in a traditional software development model Scope, Time and Cost are fixed whereas in Scrum, Scope is evolving. So there are two ways Releases can be planned.

1.              Feature Driven Release Planning (Fixed Scope)

2.              Date Driven Release Planning

Feature Driven Release Planning:

1.              In Feature Driven Release Planning, the features are fixed for the release. 

2.              Calculate the total Story Points of the features identified for the release.

3.              Add up the Story Points of all the features and divide the sum of story points by expected Velocity.

4.              This will give you the number of Sprints needed to complete the required functionality.

5.              Based on the Sprint numbers you can arrive at the release date.

Date Driven Release Planning:
In the Date Driven Release Planning, Release Date is fixed and a number of features delivered by that date can be estimated based on the Team's Velocity.

1.              Calculate the number of Sprints for the period of given Release Date.

2.              Calculate the estimated Velocity of your team by one of the methods mentioned above.

3.              Multiply the Velocity by the number of Sprints for the given Release Date.

4.              It will give you the total number of Story Points that can be completed within the given timeline. 

5.              As the Velocity of the team changes from Vmin to Vmax, the total Story Points delivered changes.

The final step of Release Planning is drawing a Release Burndown Chart. Based on the Story Points, Velocity, and Planned Sprints, Release Burndown Chart is developed. The progress of the project can be tracked with the help of Release Burndown Chart.

Estimated Velocity of Scrum Team: 
There are two methods the Velocity can be calculated.

1.              Velocity based on Historical Data

2.              Velocity Estimation with no Historical Data

Velocity based on Historical Data:
The Following graph represents the historical data of multiple Sprints. Based on this data we get Avg. Velocity (Vavg), Maximum Velocity (Vmax) and Minimum Velocity (Vmin) of a Team. 

Velocity Estimation with no Historical Data:
When there is no historical data then the Velocity can be calculated by using the following method.

Based on the team size and availability, calculate the capacity of team. (e.g. 300 Hours)

1.              Select high priority user story from the product backlog

2.              Breakdown the user story into tasks.

3.              Estimate the tasks in terms of hours.

4.              Add the hours of all the tasks of user story.

5.              Now check if there is more capacity for a Sprint. 

6.              If yes, then repeat the same exercise for the next user stories till you are full with your team’s capacity.

7.              Add the total Story Points of User Stories selected for this Sprint.

8.              This will give you the velocity for the first Sprint.

Once you have your prioritized Product Backlog and an estimated Velocity, you can start working on release planning.

Release Planning:

As mentioned above, in a traditional software development model Scope, Time and Cost are fixed whereas in Scrum, Scope is evolving. So there are two ways Releases can be planned.

1.              Feature Driven Release Planning (Fixed Scope)

2.              Date Driven Release Planning

Feature Driven Release Planning:

1.              In Feature Driven Release Planning, the features are fixed for the release. 

2.              Calculate the total Story Points of the features identified for the release.

3.              Add up the Story Points of all the features and divide the sum of story points by expected Velocity.

4.              This will give you the number of Sprints needed to complete the required functionality.

5.              Based on the Sprint numbers you can arrive at the release date.

6.              As Velocity of Team changes from Vmin to Vmax, the number of Sprints needed to complete required functionality as well as release date also changes. 

Date Driven Release Planning:
In the Date Driven Release Planning, Release Date is fixed and number of features delivered by that date can be estimated based on the Team's Velocity.

1.              Calculate the number of Sprints for the period of given Release Date.

2.              Calculate the estimated Velocity of your team by one of the methods mentioned above.

3.              Multiply the Velocity by the number of Sprints for the given Release Date.

4.              It will give you the total number of Story Points that can be completed within the given timeline. 

5.              As the Velocity of the team changes from Vmin to Vmax, the total Story Points delivered changes.

The final step of Release Planning is drawing a Release Burndown Chart. Based on the Story Points, Velocity and Planned Sprints, Release Burndown Chart is developed. The progress of the project can be tracked with the help of Release Burndown Chart.