The idea behind the fixed length sprint is to provide a understanding between development and the customer (or PO) when something new (and working) will be available, and to define the length of the feedback loop, which is equals to the length of the sprint.

In other words, the customer will know that she will get something in 2 weeks, which works, and the development team will know that they'll receive feedback on their work and know more about the upcoming work in two weeks. **That's predictability**.

Let's get back to the feedback part. The length of the sprint helps you find the right balance in work. You cannot really take more work than you can do in two weeks, so **an agreed length can take of an unnecessary pressure from the development team**.

If your feature set takes three weeks, then you have to find way to break it down into smaller tasks or user stories. **The whole idea behind Scrum is to shorten the feedback time**. If you spend three weeks on a user story you'll get feedback minimum in three weeks. If you manage to break it down to three, one-week long user stories, the first feedback will arrive in one week, which is extremely good.


> Why not just set your goals for the iteration and finish them in the time it takes rather than have a fixed iteration that you miss by finishing too soon or too late?

It really depends on the way of working you are following. Let's say you are working alone, and the next team or group which will get your code doesn't care when it arrives, then you can switch to a continuous model like Lean (or Kanban). If they want to receive your work in every two weeks, then you don't have other choice to deliver in a two week long cycle (unless you can convince them to switch to a continuous model).

Before picking a model check the whole system (from customer back to the customer) and **pick a model which provides the following benefits: quality, speed, reliability and predictability**.

The last thing: **stick to the model**. If you are doing (or have to follow) scrum than dynamically changing the length of sprint is out of question, because without a fixed sized sprint it simply won't work, because you'll lose the speed, reliability and predictability.