How we can convince a product owner to allow story points represent complexity and not time?

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