Is it common to have QA and Product Management in sprint planning? Cuz they are derailing sprint planning SO MUCH!!! I am internally screaming. Aaaaaaaaand they just extended the scope of one of the issues. Neat.

Aaaaaaaand another ticket has been rescoped.

Yes, at bad enterprise customers who can't differentiate between a chicken and a pig.

Sounds like you've got some pain in your future

Aaaaaand the director of the project just joined the call and we have to go over the entire fucking sprint again. And it sounds like we're being rescoped again. And we're being told to retitle a ticket because he doesn't understand what it means. And we're being told to link two unrelated tickets because he doesn't know what the fuck our system looks like in code nor backend. I'm about to scream externally.

Our 1 hour meeting is now extending into another meeting. It is not engineering's doing. The discussion has been taken over by product management. They are project planning in our sprint planning meeting. There is no reason for engineering to be here at this point. And the director is now getting stuck on those issues again. That he doesn't understand. And bitching about a non-issue.

Our entire sprint has been rescoped. Literally the entire thing. What was given to us by the director and mapped out has been thrown out. And now we're road mapping on the fly. And the director is hung up on the thing we have already cleared up AGAIN!!!

Time taken on side conversation that is not involving engineers at all: 30 minutes.

Save it up and write it as a story ;)

Quote from director: "start the sprint, we'll add to it later". That's not how sprints work.

Sounds like you should just sit back and be happy you're getting paid. Or apply for the PM job and do it your way.

Part of the agile manifesto is to be transparent. I think this should apply to all parts of the development teams ceremonies and during sprint. However it appears in your situation that people have more input than is wanted so a little more process could help.
Story points is a great control for scope creep in the sprint from exuberant people.
Another part of agile (little a) is to be flexible and if something of higher priority comes in then the team can change. This should be limited and not be done every sprint and I'd ask for the user research to back up these requested changes.
The only other thing I'd mention is that, yes, you should involve your QA and PO in sprint planning.
The most important part of setting up your sprints is refinement. Use it to break stories down into technical tasks. Invest more time in this.
Sprint planning should be a short session to choose stories that meet your definition of 'ready'.

There's an art to running good scrum ceremonies. If you fuck it up, a sprint planning can turn into a half assed design meeting. You gotta make sure everyone knows what the scope of the meeting is and shut em down if they try to creep.

QA should be in there I feel, since they're part of the team. There should be one product owner in there that can represent external stakeholders while supporting the team. Other product people can heck right off. They won't get anything out of a sprint planning if it's done right. If they want something they're meant to go through the product owner.

But even then people are gonna derail it if you let em