...you have Product Backlog in place and you are using Product Backlog Items that form concrete product increments. You have estimated Product Backlog Items (PBIs) in your Product Backlog and you know the velocities of all of your teams. Teams have different velocities. Fixed Work is used make all work accountable. There is an ordered list of features that are to be released in the next versions.
✥ ✥ ✥
Product Owner wants to know when the next release(s) is coming out and which features the release has.
All features won't fit in to the next release and the features has to be ordered according to their ROI.
Product owner probably does not need specific date, only a good estimation when the next release is probable to be ready. The scope of the release is known.
The features that are selected to the next release should have the maximum value for the customer.
Plan which features should be be released in each release version and build a road map basing on this plan. Ideally the features chosen for the next release are the items in the top of the product backlog. Count how many units of estimation, e.g. story points, the selected features sum up to and use the known velocities of the teams to calculate the release date for each version.
✥ ✥ ✥
For example, in Fig. 1 three next releases are shown. There are features assigned to each release and features has tasks which are estimated in units of estimation, which in this case are story points. These add up to the total amount of story points required to be done until the release is ready. There are four teams (A,B,C and D) which velocities are known. These add up to 520 story points per sprint. This would mean that Release 1 one would take three sprints to complete (1250 divided by sum of the team velocities). If sprint length is three weeks, it would mean that the release is coming out in 9 weeks.
However, there is a liability in this approach. The teams' sprints may not end in the same time. So that has to be taken into account when calculating the release date(s).
Using this approach you can have estimated release dates that can be updated according to team velocities.
Even though sprints timebox work in Scrum, it is useful also to timebox the releases. It motivates the teams as once the release is shipped they can see that something is actually done and shipped. This applies when the product increment of each sprint is not necessarily shipped.
Timeboxing the releases also give structure to the work and helps to understand which PBIs are on the critical path. It might help to figure out the dependencies between the items as well.
However, the release date should not be used as a fixed date. See the pattern Release Range.
Author: Veli-Pekka Eloranta