I am supporting and coaching several scrum teams working on different areas of the same software project. Sprints are 4 weeks long, except that sprints spanning the Christmas/New Year holidays are 5 weeks long. (The first six or so sprints were 3 weeks, before the teams decided to change them to 4.) All of the teams' velocities have a very noticeable pattern of zigzagging, where velocity alternates between higher and lower values every single sprint. In the graphs below, the Y axis is points Done per sprint; the gray lines are 10 story points. Each team has an independent backlog and estimates its own stories, so while points are not consistent between teams they are consistent within teams. In raw numbers one team completes twice the points of the other teams, so the graphs are normalized across teams under the assumption that each team's average velocity is equivalent, to prevent "point competition".
The teams explain this variation as having mostly Done stories carry over to the next sprint, so that some sprints finish fewer stories and other sprints finish more. Teams typically commit to a third or a half more points than they actually finish, and many of these extra points are "In Development" at the end of each sprint. Developers are resistant to smaller stories or shorter sprints as they "wouldn't have time to finish anything" and "would always be in Scrum meetings".
This is related to Team velocity fluctuates a lot, how to find the root cause?, but I think it is a much more specific issue. From those answers, I considered impediments and unbalanced work as possible explanations, but they aren't enough by themselves to cause this extreme zigzagging. Turnover on the teams is low and much of the velocity variation has occurred during periods of stability.
1) Have you seen such consistent zigzag patterns in velocity on your teams?
2) Does this pattern suggest a problem?
3) If so, what is the problem, how it is harmful, and how is it correctable?