Harmonizing User Story Estimatimation across Scrum Teams !!

I'll start with the obvious.  Have you ever seen anything mentioned the Scrum Guide about an Agile Manager? Or anything about having cross team harmonization on anything? And for that matter, can you find any reference to user stories or story points? 

This is a quote from the Scrum Guide's section that explains the Scrum Team.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Since you have an Agile Manager dictating conditions on the Scrum Teams, what do you think that says about your organization's commitment to having Scrum succeed?

And before you say something like "how do you compare teams/developers to each other if no one works in the same way", I will answer.  You don't compare teams or developers to each other.  Each team is responsible for their own work, the value that they provide to the stakeholders, and holding each team member to be professional. 

As a Scrum Master you have responsibilities to your organization.  This is from the section of the Scrum Guide that explains the Scrum Master role.

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;

• Planning and advising Scrum implementations within the organization;

• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

• Removing barriers between stakeholders and Scrum Teams.

This sounds like an excellent opportunity for you and your fellow Scrum Masters to help the organization.  

Now, some questions you could ask your Agile Manager.  

• What is the reason for this?  What benefit does it provide our Scrum Teams to consistently deliver value to our stakeholders?
• Why do you want to create an impediment for our teams by instituting these policies?
• What is wrong with the way we work now?  what evidence do you have that we failing to deliver valuable usable increments in each Sprint?

I'm not an advocate of using user stories or story points but I have used these quite successfully.

• What does 13 story points mean? If each team has a different perspective on points, why would standardizing on this provide any benefit?
• Have you considered that teams may start increasing their story point estimates to meet these rules and that no change in the delivery of value will be realized?

I would recommend that the people at your company read Ron Jeffries' article "Story Points Revisited". He worked with the XP team that developed the original ideas behind stories and story points and isn't really that thrilled with how story points are used today, to the point of being sorry for perhaps inventing them.

It seems like management is trying to force points back into ideal days. At that point in time, you might as well use real units and estimate in ideal hours or ideal days to begin with. That would at least make it possible to look at actual time and figure out how many clock hours equates to an ideal hour or what the team's load factor is.

However, since there's so much energy being spent on estimation, I'd even present the idea that spending so much time on estimating is wasteful. Estimates are only useful to the team at planning time. Perhaps using the flow metrics of cycle time and throughput would be just as useful and would allow the teams to plan based on actual historical performance rather than guesses and estimates made at or before planning.

Having individuals commit to story points doesn't sound very productive. Wouldn't it be better to have each team commit to a valuable Sprint Goal which the members have agreed, and which they achieve by self-management, rather than by having a so-called "agile manager" trying to tell them what to do?

I agree with @Thomas. If the Agile Manager is trying to do something so that forecasting/planning is easier, this would be a better option.  Read these books from Daniel S. Vacanti.

• Actionable Agile Metrics for Predictability 
• When Will It Be Done?

Those two books can help you with the flow metrics that @Thomas mentioned and how to understand their use.  But as I said before, they benefit each team individually and should not be used to compare across teams.

But if this is not about forecasting or planning, I stand by my first response.