Forecasting product progress with multiple Scrum teams
Hello everyone,
According to the Scrum Guide, one of the things a Product Owner might do during the Sprint Review is to project likely completion dates and to review timelines and budgets. This implies that the product owner should be able to use past data and perhaps estimates of the remaining work (provided by the development team, of course) to get a rough idea of the timeline.
On past projects, we've been able to do something like this using the team's velocity and their estimates of the product backlog. The projections were, of course, only reliable in the short-to-medium term, as the backlog was not detailed enough beyond that. In addition, as sprints are completed and new information becomes available, the product owner had to revise the projections, which were very much likely to change. Still, the little data we had allowed us to give the stakeholders a rough idea of when things might happen.
Today, I am looking for advice as to how we might adapt this for multiple Scrum teams working from a single product backlog. Each team has their own velocity, of course, but also their own method of estimating. In practice, all teams use story points, but the story point estimate for one team does not necessarily match the one another team would've given. This works as long as the sprint backlog is prioritized, as a team can simply take from the top of the product backlog according to their own velocity and their own estimates when they begin a sprint.
The problem is that these multiple conflicting methods of estimation make it much more difficult for the product owner to make projections. We would like to get rough estimates from the development teams of the relative size of the work, but at the same time would rather avoid having all the teams estimate everything. At the same time, we would like to have estimates, precise or not, ahead of time, without necessarily knowing which team will take the work in the end. This is, of course, for the sake of allowing the product owner to provide insight into the timeline to the stakeholders.
Do you have any advice?
In a Nexus where multiple teams are drawing work from the same Product Backlog, joint Refinement sessions may be held. These sessions allow a forecast to be made of which team is likely to be working on what, and for dependencies to be resolved once a suitable level of backlog decomposition is achieved.
Two possible options are therefore as follows:
1. Add one or more properties to the Product Backlog to capture the forecast of which team is likely to action a particular item, and use this to give context to the relevant team's estimate
2. The teams self-organize attendance in such a way that a consistent single estimation method emerges