The point of a sprint is that you shouldn’t sustain your pace. You should reach a given point and stop.
The problem is that far to many programmers “sustain their pace” by implementing 1/3 of 4 things in 2 weeks instead of finishing a single thing completely. That’s not a problem in waterfall if your 100% sure that those 4 things will have to be complete over the course of 30weeks, but in scrum you are trying to deliver small increments to your customer to have them validated so you don’t spend 30 weeks on something that ends up not meeting client expectations(even if it does meet specified requirements exactly)
Of course, Scrum is concerned with sustainable pacing: avoiding end of waterfall "crunch", setting estimation horizons that are sustainable (developers are terrible at estimating things in two-week time periods, but developers have an impossible time estimating anything beyond that), modest attempts at preventing burn out, even regular "small increment" delivery is itself an attempt at sustainable pacing (rather than big blow out quarterly releases, for instance).
> You should reach a given point and stop.
"And stop"? I would almost pay to see a Scrum team that allows front-loading stories and pays for time off if they are completed ahead of sprint deadlines. That sounds like an incredible unicorn.
There's no stopping in Scrum. There's always "pick a new story off the backlog" and there's always an infinite backlog to pick from, in my experience.
The problem is that far to many programmers “sustain their pace” by implementing 1/3 of 4 things in 2 weeks instead of finishing a single thing completely. That’s not a problem in waterfall if your 100% sure that those 4 things will have to be complete over the course of 30weeks, but in scrum you are trying to deliver small increments to your customer to have them validated so you don’t spend 30 weeks on something that ends up not meeting client expectations(even if it does meet specified requirements exactly)