What is the right sprint length?
Well, it pays to consult the thought leaders on this one. I’m told Ken Sipe does one-weak sprints, when he’s not busy piloting his single-engine plane deep into the bush on an obscure errand somehow related to an enterprise SOA deployment. Jared Richardson prefers a more moderate two weeks—life just has a slower pace in the South—and of course there’s a whole slew of lesser Agilists who claim you need a lavish three or four weeks to really find your stroke and make a productive team.
Of course, it all depends on what kind of project you’re talking about. Because for software, sure, two weeks is great, but if you’re taking advantage of amazing late summer weather and a few pleasant weeks on the bench to do some regrading of a troublesome patch of back yard, about two hours seems to work well.
Just saying, is all.
Tom Flaherty Said,
October 1, 2008 @ 12:09 pm
I agree.
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.
tlberglund Said,
October 1, 2008 @ 1:50 pm
Tom,
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?