This brings up such a good point. Here are the considerations I would use in attempting a serious answer the question—quite unlike my original post:

On the one hand, allowing variable-length iterations seems to be consistent with Agile principles in that it tries not to impose ceremonial constraints and lets the behavior of the team unfold as the team likes.

On the other hand, perhaps it is not in the grammar of Agile to avoid all constraints entirely, but only those constraints that are truly ceremonial and not essential (to borrow from Neal Ford’s extremely useful categories). Viewed this way, we could say that the regular rhythm of calendar-based iterations is a good way to pace teams and a constraint we should celebrate. Riffing on my “Humanity of Agile” article, I could say that people naturally pace their lives based on periodic astronomical events (days, months, seasons, years, etc.), so pacing our sprints based on a certain number of days is a typical and expected things for human software developers to do, and we should be happier and more relaxed when we do it.

Of course, I know Jared Richardson in particular has said that with advanced teams, he’s gotten away from calendar-based iterations and gone to feature-driven ones, which would seem to go better with your point. But man, talking about lunar cycles sure does sound *deep*, doesn’t it?

I personally feel that setting an arbitrary sprint length runs counter to the adaptability inherent in Agile. So to fully realize the benefits of any milestone I recommended that sprint lengths adapt to the task at hand.