by Business Analysis,

A release is of paramount importance for a software project. It may contain new features, bug fixes, or performance improvements for the system. The stakeholders affected by the items in the release eagerly await the expected release, as business processes may be on pause due to the bugs or awaiting new features.

During my time working on agile projects, I have often encountered situations where a release is not delivered on time. This always causes frustration among stakeholders and business users.

This is often caused by poor release planning or a lack of release planning altogether. Luckily, there are methods to effectively plan releases and avoid situations where the team falls short.

Release planning typically happens in one of two ways. The first is with a fixed scope, whereby we want to know how long will take to deliver the items agreed upon in that scope. The second is when we have a fixed date or time, whereby we want to know what can be delivered within a specific timeframe.

Let’s start with a fixed scope release. From the story map, we aim to release everything in Release 1.0.

Since we already know the scope and the date is variable so the question is when it will be done? To answer this question, we need to have the following information:

1. Sprint Length in weeks
2. Velocity (or velocity range)
3. Total estimate for selected stories in Release 1
4. Total Estimate / Velocity = Number of sprints (this is the number of sprints that you will need for the fixed scope release)
5. Number of sprints * sprint length = Duration

Let’s try the calculation using some hypothetical values.

Sprint Length = 2 weeks

Total estimate of user stories in Release 1.0 = 120

Velocity range = 15 to 20

Cost= 50K per week

Let’s perform the calculations based on the above values:

• Number of sprints (at high velocity i.e., 20) = 120/20 = 6 sprints (based on formula at 4)
• Number of sprints (at low velocity i.e., 15) = 120/15 = 8 sprints (based on formula at 4)

So, it will take between 6 to 8 sprints.

• Duration = 12 weeks (2 * 6) to 16 weeks (2 * 8) (based on formula at 5)
• Cost = 12 * 50K to 16 * 50K = 600K-800K

Now we know that for release 1.0 we will have 12 to 16 weeks and it will cost between 600K to 800K.

Fixed Date Release (with variable scope)

Next, let’s explore the Fixed Date Release with Variable Scope. In a fixed-date release, the duration is fixed, and you’re trying to identify what can be released within that period. For example, if it’s an eight-week release, you want to know what can be accomplished in those 8 weeks.

To identify what can be released on the fixed date, we need to have the following information:

• A groomed backlog (Items are prioritised as high and low)
• Calculate the velocity range
• Sprint Length
• Calculate the number of sprints
  • In the fixed date release, number of sprints is calculated by dividing the number of weeks in the release by sprint length. So, for an 8-week release and a sprint length of 2 weeks, the number of sprints required becomes 4.
• Calculate Release Capacity = Number of sprints * Velocity (use low and high velocity range)
  • This will give minimum and maximum number of story points that can be released in the upcoming release.
• Include items from backlog (starting at top) until total points exceed range: will have (minimum range) and might have (maximum range).

Let’s take an example to understand this better.

• The next release is in 8 weeks
• 2 weeks sprints
• The velocity range is 15 to 20
• Number of sprints = 8/2 = 4 sprints
• Minimum scope = 4 * 15 = 60 points
• Maximum scope = 4 * 20 = 80 points

So, if we consider the high velocity of 20, we can aim to finish up to 80 points. If we consider 15 points, we can achieve 60 points of work in this release. In this case, we will be able to select something between 60 to 80 points.

Let’s look at our groomed backlog. The items are prioritized from high to low with their estimated story points.

If we count from left to right, the first five stories add up to 60 points (10 + 5 + 15 + 20 + 10). We know that we will be able to finish the first five stories because 60 is our minimum capacity.

The next 4 add up to 20 points (5 + 5 + 5 + 5). This falls within the range of maximum capacity, which is 80, assuming the team goes with the highest velocity of 20.

Items further down the backlog are not likely to be finished as they exceed the maximum capacity limit.

If we have a known velocity range and a groomed backlog, then we can determine what we will be able to release, what we might be able to release, and what we won’t be going to release.

With these methods in hand, we can communicate the release plans with confidence and never over promise or underdeliver.