.
These tips are generally not a part of Scrum according to the Scrum Guide, unless specifically noted as such. They are my own personal tips based on my Scrum Coaching experiences and I do believe these tips are consistent with the Scrum Guide.

Product Owner Manages/Estimates Release Dates

To make sure I'm clear here, the Product Owner is responsible for managing and estimating release dates. This is pretty clear in the Scrum Guide. While the development team owns and creates estimates for Product Backlog Items, the responsibility for estimating/predicting release dates and/or release scope falls squarely on the shoulders of the Product Owner(PO). Hopefully the PO is using the Release Burndown to help predict release dates as well. The Release Plan and Release Burndown are generally initially created in the Release Planning Meeting by the PO, but they should be updated about every Sprint or so to reflect the results of each Sprint.

A Note on Terminology

In this article, I use term "Velocity" to indicate a completion rate for Product Backlog Items. If one uses User Stories and Story Points, then velocity is defined just as it is in the User Story practice. If one uses something other than User Stories for Product Backlog Items, or uses something other than Story Points for estimation, you'll have to adjust the advice below accordingly.



I. Date Driven Releases

The 'Fixed Release Date' method

Estimating release dates when you have a fixed release date is easy. All you do is say "Assuming the release date stays the same, the release date will be the release date!. Of course, how much scope we release is another question altogether. That will depend on the features that I, the Product Owner prioritize for release."

The 'Hi/Low/Average' method (for estimating the scope in a date driven release)

Steps

1. Come up with a forecast estimate for average velocity.
2. Come up with a forecast estimate for low velocity.
3. Come up with a forecast estimate for high velocity.
4. Feel free to change the above forecasts to reflect any major data anomalies that you know to be true.
  • Examples:
    • "These historical velocity values reflect Team Member Billy being on the team, but he is no longer on the team"
    • "These velocity figures are based on team working on the website, and this release is about mobile features, which is something that the team is less familiar with")
5. Say something like:
    • "Based on my velocity forecasts, and assuming nothing else major changes:
      • We should definitely finish these features: <list features, PBI's, stories, epics, or themes>
      • We should be able to finish these features: <list features, PBI's, stories, epics, or themes>
      • We may be able to finish some of these features: <list features, PBI's, stories, epics, or themes>
    • We'll be able to predict better as we get closer to that time frame."


II. Feature Driven Releases

The 'Rough number of Sprints' method

This is my first preference, and it goes something like this:
"We have 34 story points to do, including release work. Our current rate is 12 points per sprint. 34 / 12 = 2.83 sprints, so [rounding up] 3 sprints from now, or X weeks. This, of course, assumes that we work only on the features for this release, and that there are no other major changes that could affect the date. If you take a look at this Release Burndown, it essentially tells you the same thing."

The 'Hi/Low/Average method'

If the 'Rough number of Sprints' method does not satisfy stakeholders external to the Scrum Team, then a somewhat more scientific/mathematical(but still fairly simple) approach can be applied.

Steps

1. Come up with a forecast estimate for average velocity.
2. Come up with a forecast estimate for low velocity.
3. Come up with a forecast estimate for high velocity.
4. Feel free to change the above forecasts to reflect any major data anomalies that you know to be true.
  • Examples:
    • "These historical velocity values reflect Team Member Billy being on the team, but he is no longer on the team"
    • "These velocity figures are based on team working on the website, and this release is about mobile features, which is something that the team is less familiar with")
5. Say something like:
  • "Based on my velocity forecasts, and assuming nothing else major changes, we should be finished in about 9-13 weeks. We'll be able to predict better as we get closer to that time frame."



III. Major changes

Certain major changes can affect a feature driven release date or scope in a date driven release.
What are examples of "major changes" that could impact releases?
  • Changes in team composition or team member availability
  • Changes in PBI prioritization
  • Major changes in PBI scope