Scrum advocates the use of fixed length sprints. The length of the sprint can be adapted to balance between the need to release rapidly and allowing enough time to complete a useful amount of work in each sprint. Once an appropriate length is found, it generally stays the same.
While fixed length sprints are an improvement over waterfall style development in many respects, it imposes an artificial deadline for teams and this can cause inefficiencies and technical debt.
Sprints may have fixed lengths but user stories, on the other hand, are not homogeneous at all. Stories differ wildly in complexity and the time required to complete them. Teams will estimate their size and then commit to completing a certain number in a sprint. Seems reasonable enough but….
A scrum team will ALWAYS either over-estimate or under-estimate the amount of work that can be completed in a sprint.
This leads to one of four possible scenarios occurring.
Scenario 1: Team under-commits a lot
If a team under-commits a lot, it is usually not serious as a new story can easily by in-scoped, which will lead to one of the other 3 scenarios being triggered.
Some teams may in fact work more slowly in order to prevent a new user story being in-scoped, either consciously or unconsciously. This risk, however, probably only applies to highly unmotivated teams.