How should a Product Owner deal with unrealistic top-down release deadlines?

The deadline is the end of the Sprint, every time.

What experiments need to be conducted each Sprint, so any assumptions being made can be validated? From what you say, there isn't a shred of evidence that scope, time, quality or even budget are realistic and under control.

You’re absolutely right that the only real deadline in Scrum is the Sprint. The issue I’m facing is that in my organization, release dates are being set externally not by the teams, and not based on Sprint cadence or empirical delivery data. Which in itself is an issue, i dont know how to solve.

I’m trying to push for transparency by showing the team’s velocity and using that to forecast what can actually be delivered. But when the Product Manager or other stakeholders say, “this has to be in Release X, no matter what,” it puts me in a difficult position as a PO: either I defend the team (and look like I’m resisting) or I say yes (and commit to the impossible).

Perhaps you have heard of the Iron Triangle, sometimes referred to as the Triple Constraints? It is typically used in project management but the concepts work for Scrum, too.

In product development, you can fix two of the three sides of the triangle: scope, time, and budget, but not all three. If both the delivery date and scope are fixed, something else has to give. Scream from the roof top how this will impact quality, team morale, and sustainability of the product. I foresee lots of tech debt and bugs, and aburnt out team.

Fixed dates are okay, if scope is flexible Scrum doesn’t reject deadlines. But it assumes we’ll inspect progress and adapt the scope as we learn more. If everything is a must-have, it usually means priorities haven’t been clarified.

Use the Sprint Review to make progress and tradeoffs visible. Show what’s been delivered, what remains, and what’s realistic. This is where conversations about scope, dates, and budget should happen with stakeholders using with real data.

I wonder where your Scrum Master is? This is exactly where a strong Scrum Master could step in, coaching stakeholders on empirical planning and protecting the team from unrealistic expectations. You shouldn’t have to carry this alone.

I'm vaguely familiar with S@S. Isn't there a meta team you can bring this to?

Courage and Transparency - two things to get you through this!

I’m familiar with the Iron Triangle, but I really appreciate you bringing it up again. It’s definitely a concept I should be using more often in my communication with stakeholders. Thanks for the reminder.

Regarding quality: we’re already dealing with a huge number of bugs, more than any other team in the company. That alone might be the best proof that planning in the past followed exactly the broken model you described: fixed time, fixed scope, zero flexibility.

Burnout is also no longer theoretical. Some developers are already approaching the edge. It is already a big problem.

Our Scrum Masters are trying hard to coach and educate, but at the management level, it’s largely being ignored. We do have a MetaScrum in our Scrum@Scale setup, and we’ve addressed these issues there but so far, unfortunately, without any meaningful change.

I think what I take away from your post is this: I need to get louder. Use the triangle. Show the burn. Make the trade-offs visible. And most importantly: stop carrying it alone.