Simplifying Estimation & Release Planning in Agile

Aren’t these ones of the few aspects that we try to address, figure out, and balance while planning for the Release(s) of a product.

Often Agile teams are asked by Business / Client teams to come up with visibility & plans for Milestones and Release(s) for the Product.

The Waterfall model makes it easier to prepare a Release Plan, due to its inherent approach. However, as Agile works in an Iterative and Empirical approach, it becomes difficult and challenging to prepare a Release Plan upfront.

This article attempts to simplify and present a suggestive End-End approach towards Release Planning.

We will start with understanding the Basic Agile Estimation Approach and then its application to estimate a high-level backlog and then render a release plan.

Step 0 — Understanding the Estimation in Agile — Story Point Approach

Let’s start with understanding the one of most common Estimation Approach in Agile — Story Points.

Principle: Size the smallest understandable thing first and then size everything else Relative to it !!

Unit of Estimation: Story Points

Components: Story Points sizing involves the following factors:

1. Efforts required to complet the Story
2. Complexity of the story
3. Risk — What’s unknown against What’s known
4. Relativity — Idea of size against the known story

Let’s understand by an Analogy as in the diagram below.

We have an entire backlog to deliver i.e. from Skateboard to the Rocket. But we do not know the size of the entire backlog and hence difficult to plan. So we start with estimating the smallest and easiest item, which is ‘SkateBoard’ in the diagram below.

We size ‘SkateBoard’ to 1 story point, then the tricycle can be sized at 2 story points, the bicycle can be sized with 3 story points, and so on. This way, we will be able to size our backlog.

For practical application: We can consider each of these items as equivalent to a story and can follow these principles :

1. Fibonacci Series for Story points
2. Range — 1–8 Story Points
3. Any story larger than 8 story points should be broken down into smaller stories.

(I’ll pause on the story point topic at this point, as the current article focuses on Release Planning)

Step 1 — Applying Agile Estimation — T-Shirt Sizing Approach

If our Product Backlog (Epics and Stories) is at high-level, then we can apply T-Shirt’s approach to backlog size.

Principle: Size the smallest understood thing first and then size everything else Relative to that !!

Unit of Estimation: T-shirt Sizes

Constituents: Story Points sizing involves the following factors

1. T-Shirt Size
2. Story Point Range
3. Confidence
4. Release (e.g. R1, R2, R3 …)

Descriptive image for Product Backlog and correlation to T-Shirt Size

T-Shirt Sizes: Small, Medium, Large, Xtra Large, XXL

Story Point Range: Associate each T-Shirt size to Story Points and the one correlation that works for me is mentioned below:

Story Point Range Table

Confidence: It is the team’s knowledge and understanding of the Epic/Story in question.

1. High — If the team is fully aware of what’s required to be done in an Epic/Story. We multiply the ‘Story Point Range’ by 1.1.
2. Medium — If the team has an idea but there are gray areas. We multiply the ‘Story Point Range’ by 1.3.
3. Low — If the team has virtually no idea. We multiply the ‘Story Point Range’ by 1.5.

Overall Sizing

Once the team is aware of all these factors, the next step is to apply them:

1. For each Epic/Story, a discussion is facilitated and an appropriate T-shirt size, Confidence is allocated.
2. The size is drawn in the range of Story Points using the Range table mentioned above.
3. The Confidence Coefficient is applied.
4. We can then take an average of Min & Max range of Story points for our planning purposes.
5. We then assign a release to each Epic/Story.

After all this, the backlog appears like the table below.

WBS for Release Plan

Benefits of this Technique

1. This is quite informal and quickly covers a large number of items.
2. Inspired by Relativity
3. Forces to use a fixed set of sizes
4. Helps team in getting versed with Relativity

Step 2 — Determining Team’s Velocity

Velocity is the quantity of work that can be delivered by a team in a sprint. It can be found in Jira under reports

It helps determine the team’s throughput, which in turn helps with forecasting and Release Planning.

Step 3 — Forecasting and Release Planning

For the Forecasting and Release Planning, we need to consider the Product Backlog Sizing from Step 1 and Team’s Velocity in Step 2.

Average Velocity of Team :

• 30 story points

Release Backlog:

• 240 story points (considering average story points), OR
• 200–280 story points (considering mix/max story points)

Release Duration:

• 8 Sprints (considering average story points)
• 7–10 Sprints (considering mix/max story points)

Release plan can also be extended to cater to multiple releases:

• Release 1 — Range of 8 — 10 Sprints
• Release 2 — Range of 4–6 Sprints
• Release 3 — Range of 3–5 Sprints

Sample Release Plan (usually covers a lot of other activities)

Important Points to note:

• Original estimate for a release must be used as a baseline.
• This approach is subject to regular revision and refinement of the backlog.
• In case of any change in backlog and its sizing and team’s velocity, the release needs to be reviewed.
• Tracking by Release Burnup / Burndown, Sprint Burndown charts is important to ensure the release
• Release Burndown will show gradual burn along with scope addition and Forecast.

Adjust your sails, deal with the unexpected and uncertain, instead of being angry at the winds you will never be able to predict and control.