If we unpack the reasoning behind why teams might wish to make sprints longer, certain anti-patterns tend to emerge. Anti-pattern 1: Teams are spending too much time preparing for sprint reviews/demos. Anti-pattern 2: Teams are attempting to complete stories that are too large. Anti-pattern 3: Teams are running “mini-Waterfall” sprints. Anti-pattern 4: Teams encounter problems with code merges, integrations, and deployments. Anti-pattern 5: Teams are relying heavily on individuals external to the team to ge
This article does a pretty good job at showing some of the common reasons teams say they want to have longer sprints and also showing why longer sprints won’t help. Generally speaking, if you are struggling to get stories done at the end of the sprint, you should shorten your sprint until you can be consistent. Once you are consistently getting done everything you said you would at the start of the sprint, you can make it longer again if it makes sense.
There are often systematic reasons keeping you from getting stories done in a sprint and having more time generally won’t help those. However, having more time will allow you a bigger buffer to ignore those problems. A shorter sprint length makes it harder to ignore those problems and thus they become more obvious, making it more likely that you will see them and fix them.