... the Product Owner is building a Release Plan based on team velocities.
Stakeholders (e.g. managers or customers) tend to treat any single number as definitive, and they tend to treat definitive single quantities as commitments.
Stakeholder wants to know release dates, but you cannot give exact date as there might emerge new requirements or delays and in addition team velocities might gradually change.
In general, the future is uncertain in any project and the Product Owner has to live with that. Developers may leave the company, be sick, there might be unexpected server downtimes, etc. While taking all this into account, iIt is hard to give precise release dates.
When a team estimates work effort on PBIs or sprint tasks, they usually give a single number. While the team instead use Estimation Ranges, that incurs a lot of extra work, and is difficult to fit within a consensus framework. Further, this approach tends to weaken the team's sense of commitment: they will tend to be content with consistently meeting the least ambitious commitment.
Therefore: Make pessimistic and optimistic estimates for release dates based on historic team velocities. Use a high and low team velocity from the past several months to calculate, respectively, the most pessimistic and most optimistic dates for each given release. Avoid using the very highest and very lowest velocities from the period, choosing numbers that are within three standard deviations of the mean velocity. The Scrum team should accept release ranges, so that they are commited to them.
Sometimes stakeholders, however, want an exact date. For example, if the product is released in some event. If this is the case, the pessimistic estimate should be used.
If there are no historic data of velocities of the teams, then knowledge from previous similar projects in the same domain could be used or velocities of other teams. Of course, in this case, the estimates are not so accurate and it should be taken into account. On the other hand, in this case, Product Owner might want to be flexible with the release scope. Some features might need to be dropped out from the release, if it seems that the release would otherwise be late.
Release range estimate should be revisited regularly. As the project goes forward the range can be more focused.
This approach accommodates emerging requirements to get a range of release dates. Then you can tell the customer that the release will be within this range. This should be told as a benefit, not as a fuzzy thing.
You can do an analogous calculation for fixed-date planning, to report a range of PBIs that might be delivered.
Author: Veli-Pekka Eloranta and Jim Coplien