There is no way to estimate the work and predict when it will be completed. All problems are also people problems and people will always follow the incentives.
I see these problems all the time. They are ultimately a management issue. Doesn’t matter if you are talking about a roadmap or a sprint deliverable… there is not a good way to predict it with any consistency. Adding in more people will not help either. Does t matter if it’s a delivery lead a scrum master or whatever. It usually just leads to overestimates by the dev team. It makes the sprint deliverables look good… but for what? Vanity metrics.
Thin slice the value of what you are delivering, move to Kanban, and release to prod daily or as often as you can.
If you constantly deliver value and solve problems… no one will care about sprint deliverables. These are things a PM can solve without needing additional people.
To be completely honest, it sounds like y’all are just making up the rules as you go on all sides.
“Release timelines”, “delivery timelines”, “sprints”, PO, Scrum Master, etc. are all constructs that you’ve either explicitly or implicitly agreed to, however, none of them have to exist if they aren’t helpful or you aren’t following some sort of framework (sounds like you’re roughly doing scrum but not really for e.g., We Tried Baseball and It Didn't Work).
How big is your org? Who is driving this made-up process? What’s the actual outcome you’re trying to achieve here?
If you’re trying to drive a fixed timeline delivery cycle, then you have to make the scope variable. In other words, if you have two weeks sprints, the scope of the sprint is going to be variable. If your goal is to increase the velocity of the team, arguing about who’s responsible for being responsible is… uh. “Not it chief” to use the parlance of the time.
If your developers can’t ship because their code is buggy and untested, then I’m not really sure why you’re on the support community and not re-writing your resume and applying elsewhere?
Probably both. You need to get the PO, Scrum Master and yourself aligned on timeline requirements. This is the same as getting buy-in for requirements. Let them lead the discussion portray the vision and help them see why it’s okay to have a few things fall behind.
My guess though, this is a people management issue. The scrum master sees their KPIs as sprint completion percentage or they are just managing the scrum poorly. Help them understand part of their job is ensuring sufficient work is placed in a sprint and not just completing the sprint. Adjust the KPI to time between in progress and complete or UAT, instead of percentage of sprint completed. That way they can see that some cards take two days others take weeks. And they have a frame of reference for what to put on the next sprint. Ideally, they’ll measure each cards estimated time in progress. They have the same goals, just if a card started on Thursday and carried over to Monday, it doesn’t hit their sprint metrics.
But I’ll say this. If you have to ask who is responsibility it is to do XY or Z, the answer will always be yours.