Scrum prescribes no forecasting technique. The Guide names burn downs, burn ups and cumulative flow as practices that exist and have proven useful, but it adds that they do not replace the importance of empiricism. How a team arrives at a date is left entirely to the people doing the work.
That silence is easy to read as a gap in the guidance, but it works more like a warning. Every practice the Guide names projects forward from what has already happened, so none of them makes the future more knowable than it is.
Forecast and commitment are different things
The Guide does draw one line precisely, and it runs through the Sprint Backlog. The Sprint Backlog contains the Sprint Goal, the selected Product Backlog items and a plan for delivering them. The Sprint Goal is the commitment, while the item list is a forecast, which is why the Developers may clarify and renegotiate scope with the Product Owner as more is learned, so long as the Sprint Goal still holds.
A stakeholder treating a projection as a promise is the usual setup for a scenario question here. The answer is almost never longer hours, because the forecast was a statement about what was expected at the time and new information is supposed to change it.
What a Scrum Master does with a forecast
Carrying that point to the stakeholder is usually the Scrum Master's work, since the person treating a projection as a promise sits outside the team. Removing barriers between stakeholders and Scrum Teams is one of the Guide's four services to the organisation, and a stakeholder who reads a forecast as a commitment is that barrier in its most ordinary form. The same list puts the teaching of an empirical approach to complex work in the Scrum Master's hands, so explaining why a projection moved is the accountability being discharged.
Two moves sit outside that accountability. The first is reporting the team's progress against a plan, which puts the Scrum Master back into the reporting chain Scrum took them out of. The Sprint Review is where progress is inspected, and the people who did the work are the ones who show it. The second is requiring a velocity figure, which adds a rule the Guide does not contain and hands the measure to whoever asked for it.
A range says more than a date
A number handed over on its own invites a second question, which is how certain it is. An average turns a spread of outcomes into one number and then hides the spread. A team building an internal admin tool has finished between four and eleven items in each of its last ten Sprints. The average is 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. A single date cannot do that. A range also narrows as observation accumulates, which is what the empirical loop looks like from outside.
Velocity is absent from the Scrum Guide
One figure in particular gets treated as though the Guide required it. The word velocity does not appear in the 2020 Scrum Guide. Velocity is a widespread practice that the framework never asks for, so no team is obliged to produce the figure.
Velocity does its real damage 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 is the count of items finished in a Sprint, so it at least counts real things, but it still does not compare across teams whose items are different sizes.
Padding protects the forecaster
A measure can also be distorted on its way to the person who asked for it. 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. The planner then briefs a sales team or books a launch against a figure that has been quietly adjusted, and the margin is usually consumed anyway, because work expands into the time allowed. The repair is to publish the range and the confidence attached to it, which hands the planner the information the padding was concealing.
When the date and the scope are both fixed
Honest numbers eventually force the question the padding was deferring. A fixed date and a fixed scope can both hold only if the work turns out exactly as expected, and it rarely does. 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, because the Definition of Done sets it. An Increment may be delivered to stakeholders before the Sprint ends and more than one may exist within a Sprint, so the timing of a release is a product decision the framework leaves alone.