Is the Scrum Master the right person to answer this question?

Without knowing all the facts, this is highly subjective. 

Team A - Possibly has more experienced, highly productive members on their Development Team. 

Team B - Possibly has many junior Development Team members, which means that senior members are having to split time between doing work and training. Also possible that some members had time-off. Also possible that some members of the team are not as productive, goal-driven or motivated as Team A. 

When I've given such "assessments" as a management consultant, I have explained that anything I state, is based on my observations and that it is not necessarily the whole truth. Management will sometimes use these assessments to make decisions on personnel.

At the end of the day, you have to remind management that they're dealing with people. Some people will be better, more productive, more efficient, more skilled and better with time management than others.

Team's should not be compared or measured using velocity. Each team can have different scale of story points and team doing 100 story points may deliver less than second team delivering only 20. Velocity should be used only by the scrum team - mostly to know their pace, know how much they could take on planning. And the senior management should receive this explanation I believe.

What should matter is how much the team delivers business value. By business value I mean how many useful features have been added by them in the sprint. Management should observe how much is produced by teams. If they need numbers, you can try to do some brainstorming how to measure that in your context.

Also - one sprint should not be deciding. We should observe teams in couple of sprints.

I would invite "senior management" to the sprint reviews. In this way they can see how the money of the company is spent, they can see what actually team did in past sprint. And they can provide feedback. If they have doubts team is implementing useful features, they should discuss this with the PO why they put these features and not the others at the top of the backlog. If they doubt about the team's speed in implementing features, they should discuss directly with the development team or with their supervisor (depending on the hierarchy in particular company). They should be able to explaing the situation precisely.

In addition to what has been mentioned about comparing teams and educating management on relative estimation, no one metric is helpful or will tell you everything. Here's why.

What if one of the Development teams were cutting corners, building up lots of technical debt and has poor quality? Or maybe not, but they are working overtime at an unsustainable pace, the developers are unhappy and about to leave the company? How helpful is velocity now?

There's also Goodhart's Law: When a measure becomes a target, it ceases to become a good measure. Sometimes people know they are being measured, and the metrics start to become 'gamed'. Let's bump that 5 pointer to an 8, we have to keep up with Team X.

Measure outcomes (related to value) rather than outputs (velocity, points). And the conversations are always more important.

Here's an article I wrote on the topic, share this with your leaders: https://www.scrum.org/resources/blog/moving-beyond-velocity

Scrum on!

Chris

what would be the best answer that the Scrum Master could give?

"What problem are you trying to solve?"

"What problem are you trying to solve?"

This and what Chris already mentioned:

 When a measure becomes a target, it ceases to become a good measure.

Satisfying metrics targets is not a goal, but having management treat it like this will distract the team for delivering value and have them focus on clearing targets. 

"Senior management" is presenting Scrum Master B with the perfect opportunity to coach them on how Scrum focuses on the value delivered and not the amount of work being done. I'd answer with a question.

Is Team B delivering value to the customer in a manner that satisfies their needs?

That is where "senior management" should be focusing their attention, not on the team's mechanisms used to relate various items of work to other items that they do.  The goal of a Scrum Team isn't to complete story points. It is to deliver incremental value at the end of each sprint. 

As mentioned previously, if "senior management" starts comparing teams ability to complete estimated work the teams will start to scale their estimates to make it appear they are doing more.  It will not be long before the 5 point stories start to become 13 points and you will start to see more 20 point stories appearing in sprints.

All responses in this thread have good advice and a pretty common message. Good luck with your coaching moment. 

Prime position for the Scrum Masters, for sure! Obtaining data is easy...but knowing what to measure with that data is not.

There's nothing 'wrong' with measuring some stuff about the team, because it helps validate improvement. What makes velocity measurements wrong is because it's not the intent of that tool. We also don't want to compare output between teams. That's not to assume measuring stuff between teams independently is automatically wrong.

That said, I have two criteria:

1. Have a single, concise use case
2. The use case connects to the purpose of Scrum

Managers need to manage, so get their perspective. Ask them what they feel they need to report on. Correlate that back to Scrum and make attempt to make a connection. 

In addition to all of the excellent advice already presented in this thread (and apologies if I am repeating any previous responses), my 'answer' ideas are as follows:

• Ask your Senior Management why they are interested in analyzing such a small sample size?
• Ask them why they believe story points are 'normalized' across teams?
• Ask them to read the following article first, and then get back to you: https://age-of-product.com/faking-agile-metrics/