Five teams sounds like a lot; building and sustaining an effective trust-based coaching relationship with more than 10-15 people is a significant challenge.

In your context I’d be looking to grow the leadership skills within the teams so that you can adopt more of a coaching stance; this seems to align with management’s expectations.

What shape that tales is context dependent. Things that have worked for me include

– sending everyone on a two-day “team member to team leader” course, across 2-3 cadres in a department of 50 people; you get about a 20% hit-rate from courses on average, but 10 new people showing leadership in the teams is a big help

– run leadership/agile workshops on an open basis; I do these on Friday afternoons. Work on core areas like facilitation, problem solving, communication, conflict resolution, negotiation, as well as agile and lean practices.

– spin up roll-centric and subject-centric communities of practice, who can take the led in developing taking agile practices forwards some of the high-performance areas covered in books like “Accelerate!”;

– look to bring the teams up to speed in problem solving techniques like “evaporating clouds” or Ishikawa fishbone; use tools like Anthony Coppedge’s retrospective radar to pull together systemic issues for management

– get a mentorship group running outside of your employer; that is to say other Scrum Masters and agile coaches who can support you, and you in turn can support them

In terms of influencing management, perhaps reflect on the skillsets you need to do this, and how you would currently rate those skills. Then look to what professional development may help. Things like leadership training, negotiation skills, courageous conversations and coaching training have all helped me.

It probably doesn’t matter very much, to be honest.

Story points were only ever “thinly obfuscated time” anyway(1) ; the aim was to stop people taking the team’s estimates, summing them, and then calling that a deadline.

If you are using Scrum, then points/velocity are just about making sure your Sprint Plan to reach a Sprint Goal is viable when you start. You’ll be inspecting and adapting that plan daily, which might mean splitting stories, pushing some items back to the backlog and pulling others in.

The Sprint Goal is a stepping stone to the Product Goal, and it’s those goals that matter.

On the other hand, if you are really focussing on delivering a backlog, then I’d advocate looking at the Kanban Method; without a Sprint Goal that might serve you better. I the Kanban Method there’s no estimation by the team. You make forecasts based on statistical estimation, using the cycle time or throughput (stories/week)

So – probably not a hill that is worth dying on, IMHO. There are probably other things that are holding the team back more….

But if you really want to unpack things, go with empiricism.

Collect data. Count the number of stories each Sprint, along with the total number of points from the completed stories. Use this in the retrospectives. Look for patterns. Would counting stories serve you just as well?

I’ve used a bubble plot with the total points (Y), number of stories (X) and the bubble size as the average story size. What does the team notice?

Start to build the idea that the team should shift from opinion-based debates to data-driven dialogues……

(1) https://twitter.com/ronjeffries/status/307469737305186304?lang=en