Why We Have Sprints
Like in all other agile methodologies, in Scrum we
Welcome [change], even late in development. — 2nd Agile Principle
So basically, requirements may be changed at any given time during a project, to maximize the product value. Which is a good thing! It allows to permanently adjust to the consumer’s needs and makes the product better.
To give Developers on the other hand a possibility to work effectively and productively, Scrum defines a timebox in which Developers are “safe” from change: Sprints.
The productivity increase that so many companies look for when implementing Scrum, is mainly a result of the ability to work without interruptions and to focus on a fix amount of planned tasks within Sprints. It is therefore vital to avoid change within a Sprint and respect the implemented Scrum processes.
If your business doesn’t allow for month long Sprints, try 3- or 2-week-iterations and see where this leads you. In the end, try to stick to this rule of thumb:
Plan sprint durations around how long you can commit to keeping change out of the sprint. — Mountain Goat Software