The goal of the sprint is -planning-. It has no effect on the devs doing work.
If we estimate what can get done for a given time period, we can evaluate whether we're correct. Do it a few times, we get really good in estimating. We can try and estimate the future. As soon as new things come in that we didn't plan for, we know immediately that we're going to slip, and may even be able to figure out by how much, or what we have to drop to still hit the date (or if we need to evaluate if more people would be helpful; PM triangle here). Likewise if we learn our estimates are wrong, we can start predicting we're going to miss the mark, literally as early as humanly possible.
Doing it this way is in response to longer term milestones; if you only estimate/evaluate once before delivery (if even that; oftentimes milestones are just "on time" or "behind", there isn't any acceptance that a date and set of features won't be hit, and it turns into a death march), you only get one chance to evaluate and respond. Likewise with two, three, etc milestones. Sprints just try to break the work up to do it more often, to try and recognize you're behind, sooner, and so can respond. They don't have to be two weeks; it's a tradeoff, the more measurements the faster you'll recognize you're off, but the more work it is just to measure.
If you don't have deadlines that the rest of the org has to organize around, or to communicate to a customer, just a very clear set of priorities, and you just pull from the top from, you don't benefit from Scrum. Which is perfectly okay. Just, oftentimes businesses -do- need things by a given date, or need to respond in some way. Sprints just help give you evaluations to determine that you're on track. Or not.
