one product backlog, multiple teams, multiple velocities, a single governance

Our stakeholders wish for a single aggregated metric to show the progress of the project as a whole

Why? Why wouldn’t the delivery of valuable and usable product increments be evidence enough?

Our stakeholders wish for a single aggregated metric to show the progress of the project as a whole and I am confused as to how to take the individual subjective velocities of each of the respective teams and translate them into one governance document which would interpret the progress of the whole project accurately.

Velocity does not measure team productivity or translate to value delivered.  Would story points completed by team tell your stakeholders anything about progress or customer satisfaction?  What if your teams completed a million points a Sprint, but customers hated the product or the product was of poor quality?  Or worse the Increment wasn't released very often?  Or the teams were unhappy and ready to leave your company?

@Ian stole my answer but he said it much more eloquently.  

If you want an "academic" reference, I suggest you look at the Nexus Framework provided on this site. It explains how 3-9 teams can work effectively from a single Product Backlog and provides some guidance on how to understand progress. 

Velocity is a planning metric for that specific Scrum Team - nothing more.   Do not use velocity as anything other than a guide, in order for the PO to forecast potential completion dates, and for the Development Team to determine the amount of items they can accept each sprint.

There are other ways for your management to improve visibility into value delivered.   Explore concepts like Functional Points, or WSJF, to learn more.   You may even decide to establish a range of numbers to represent value delivered, and then assign such a number to each PBI.

thank you for all of your responses.

a better explanation of what we are trying to achieve is, aggregate completed user stories from 3 different teams and then come up with some type of metric to measure that aggregate against the % completion against the overall project i.e. some type of release burn down... but aggregating 3 teams output if that makes sense.

regards

billy

If you can quantify value for the business per user story, you can also show how much of that value has already been delivered by the team.

Very good advise above (these folks always nail it).

I do want to point ou something that caught my attention and is, in my view, critical:

Our stakeholders wish for a single aggregated metric to show the progress of the project as a whole and I am confused as to how to take the individual subjective velocities of each of the respective teams and translate them into one governance document which would interpret the progress of the whole project accurately

If the stakeholders/management believe they will see the whole project "completed", they're in for a huge surprise, for all evidence shows no one can predict the future, no one is able to come up with exhaustive/complete requirements, no one knows what challenges would be faced, no one knows if what they build is going to be approved/welcomed by the users/market. And so forth.

Do you think it's reasonable - realistic to think the whole project would be complete? That the whole project is designed so good there would be no changes? 

There's a principle, one already validated on billions of occasions (and for decades, if not centuries), that says most benefits come from a small percentage of features - it was calculated to be around 80 - 20: 80% of the benefits come from 20% of the features; 80% of sales come from 20% of customers; etc

As a SM, it would be one of your duties to, as pointed above, explain to everyone (stakeholders, scrum teams) why it isn't that smart to look at team velocities, but rather to build in small increments against a (rather flexible) MVP and get as much user feedback as possible, with the aim to deliver what is needed/provides most value, rather than aiming to "complete" the project as it was initially thought/designed/planned.

Again, thank you for all of your replies, they really are invaluable and much appreciated.  I will endeavor to articulate these points to my stakeholders and try best to manage this relationship so that the velocities are viewed exactly as they are meant to be, a metric for the SDT, not a management report!

Having said that, from a strategy standpoint, I don't see there being anything wrong with have a high-level governance artifact which maybe catalogs all the epics as milestones and then as we complete them, monitors as a % complete.

This data could be manipulated and presented in graphical form, and I acknowledge this may not be strictly Scrum, but it does not take a lot of effort, the data is already available, I can't see it being a distraction/impediment/blocker to the SD team and would allow the senior stakeholder to feel much better to see this type of progress.

May I ask your opinions?

As always, your insights are much appreciated.

Regards

Billy

Your last suggestion, in my opinion, falls outside of Scrum and seem reasonable enough if needed.  But why is it needed? Isn't it enough for the stakeholders to see that they are getting the value they want and not necessarily the value that they thought they want?  Why would there be a need to see how many Epics are done if the stakeholders are happy with the results that they are getting?  How does showing the stakeholder that 80% of the epics are completed actually provide any measurement of the value that is being delivered? Especially when the number of epics will increase continuously. 

I can't see it being a distraction/impediment/blocker to the SD team and would allow the senior stakeholder to feel much better to see this type of progress.

I can absolutely see it as a distraction. If the teams know that they are going to be judged/measured on the number of epics that they finish, then they will be focusing on marking an Epic finished rather than working to provide the best value to the stakeholder.  It is just human nature to make the measurements of your success/failure be as positive as possible. 

The senior stakeholder needs to understand that Scrum is not judged on number of complete/done items. It is judged based on the value that the stakeholder sees in the deliverables. I would suggest that the stakeholder should be looking at how much of the deliverables over time are in use.  Otherwise, you get back to the old style of software development/project management where finishing something, even if it provides no benefit to the stakeholders, is the most important thing. 

+1

I do, however, see great value in ensuring as much visibility as possible, even at this "epics as milestones" level, on one condition: said epics are just part of a flexible goal (say, an MVP), one that everyone understands could (and very likely would) be updated to reflect the learnings/discoveries/challenges/market updates/whatever.