- Its an appropriate amount of time for teams to be focussed internally on what they have been set to achieve.
- From a higher managment perspective seeing progress every couple of weeks is nice, whereas something longer (like monthy) seems a bit too "admin" (akin to attending monthly sales report meetings) and a bit waterfall.
- If all goes wrong and a sprint is wasted, managment can "swallow" losing two weeks of time, but longer is less aceptable "what do you mean we lost a month - this is supposed to be Agile?"
- It gives an opportunity to review the supporting Agile processes (CI, TDD etc) regularly so that they can be tuned or re-engineered if there are problems, also there is more retrospective review as a whole.
- Shorter sprints mean less work-in-progress at any one time so you have potentially less integration problems and less risk of regression test failure if CI processes are not mature.
The final point I would make on spint lengths is that whatever you do choose, don't change it for the sake of it. There is little point playing a two week sprint, followed by a three week sprint, followed by a two and then a one as all it does is "upset" the rest of the organisation. "Is it sprint planning/show and tell this week?" - "no-idea, what was last week?".
So much that is external to the scrum teams needs to interact with the Agile process (Product owners, stakeholders, IT support, BAU, release managers etc) that they need the calendar to be constant so they can plan their workload. A whole organisation adopting Agile should have the sprint length as the constant heartbeat in the middle of it that everyone can "hear" in the background.