Scrum prescribes no forecasting technique. It names burn downs, burn ups and cumulative flow as practices that exist and have proven useful, and states plainly that they do not replace empiricism. How a date is arrived at is left entirely to the people doing the work.
That silence reads as a gap in the guidance and is closer to a warning. Every practice named projects forward from what has already happened, and none of them makes the future more knowable than it is.
Forecast and commitment are different things
The Sprint Backlog contains the Sprint Goal, the selected Product Backlog items, and a plan for delivering them. The Sprint Goal is the commitment. The item list is a forecast, so as more is learned, scope may be clarified and renegotiated with the Product Owner, provided the Sprint Goal is not put at risk.
A stakeholder treating a projection as a promise is the usual setup for a scenario question here. The answer is rarely that the Developers should work longer hours, but that the forecast was always a statement about what was expected at the time, and new information is supposed to change it.
A range says more than a date
An average turns a spread of outcomes into one number and then hides the spread. A team that has finished between four and eleven items a Sprint has an average near seven, and a plan built on seven will be wrong most of the time in ways nobody was warned about.
Reporting from observed throughput as a range keeps the spread where people can see it. Saying that the remaining work has historically taken between six and eleven Sprints tells a planner which decisions are safe and which are gambles, which a single date cannot do. A range also narrows as observation accumulates, which is the empirical loop working rather than the forecaster growing confident.
Velocity is not in the Guide
The word velocity does not appear in the 2020 Scrum Guide. It is a widespread practice rather than a framework requirement, and no team is obliged to produce one.
Where it does real harm is in comparison. Sizes are relative to the team that produced them, so one team's velocity means nothing beside another's, and an organisation that ranks teams this way has created an incentive to inflate estimates that costs nothing to follow. Throughput, being the count of items finished per Sprint, at least counts real things, and it is still not comparable across teams whose items are different sizes.
Padding protects the forecaster
Adding a private margin to a date feels like prudence. What it does is move the uncertainty out of sight, because the person receiving the date gets a number that looks firmer than the evidence supports and cannot see how much room is inside it.
The cost lands on the planner. Decisions that hang on the date, such as when to brief a sales team or book a launch, get made against a figure that has been quietly adjusted, and the padding is usually consumed anyway because work expands into the time allowed. Publishing the range and the confidence attached to it hands over the information the padding was concealing.
When the date and the scope both refuse to move
A fixed date and a fixed scope can only both hold if the work turns out to be exactly as expected, which it does not. Something gives, and in Scrum it is normally the scope, because an ordered backlog puts the least valuable work at the bottom where dropping it costs least.
That is part of what ordering buys. A team that built the most valuable third first has a releasable product on the date, while a team that spread its effort evenly across everything has a half finished one. Quality is not available as the variable, since it is set by the Definition of Done. An Increment may be delivered to stakeholders before the Sprint ends and more than one may exist within a Sprint, so release timing is a product decision rather than a framework rule.