Should Sprint Length Be Flexible?

Recently I’ve been writing about issues arising as we explore Agile principles within the more traditional scheduling environment of ATG. As we talk about how to schedule sprints in a Scrum pilot project, we’ve been debating key principles and how they might apply to our projects. The latest is sprint length. Should the length of your sprint be fixed or should it flex in response to the size of the tasks in it?

It’s second nature to the experienced program managers I work with to break projects into milestones, so the idea of breaking a project into sprints seems easy to adopt. According to what we’ve read, sprints are supposed to be a short (2-4 week) cycle of work kicked off when the team agrees on a list of tasks to be attempted and finished off with a review (usually a demo) of what’s been completed.

We’ve been used to determining the milestone schedule according to the size of the tasks on our list, though. A related set of large, complex tasks should require a longer time frame than a single simpler task, right? Makes sense. Scrum says you ought to be able to break any task down into component tasks that would fit into a sprint, but why force different size tasks into an arbitrary schedule? Why try to demo something that’s only half done? Is there any reason we couldn’t have a sprint of 2 weeks followed by one of 4 and then one of 8 for a really big task?

I’ve heard a few reasons that sound credible and that we plan to test.

1. Accountability – Have you ever seen a feature stay at 90% complete for weeks with no apparent progress? Have you ever seen developers procrastinate on work with a long deadline? Rapid-fire deadlines force people to get things done efficiently for fear of looking bad at the demo.
2. Course corrections – There’s always some gap between what product manager asks for and what the engineers deliver. Frequent reviews minimize that gap by bringing the two parties together regularly even when features aren’t done. It’s easier to make changes before the feature is done, tested and documented. And without the discipline of regular check-ins it would be easy to wait until back-tracking feels like more work than it’s worth.
3. Rhythm – I’ve heard people experienced in Scrum say that a regular schedule puts them into a productive rhythm. It’s like exercise, I gather – once you get to doing it regularly you begin to expect it. It’s self-reinforcing. Developers look forward to the sprint reviews and to kicking off the next round.
4. Attaboys – Steve Johnson from Pragmatic Marketing mentioned this effect when he spoke at the BPMA recently. He likened it to the increased desire of a husband to tackle items on the "honey-do" list when he gets praise from his wife for doing them. The regular demos provide an opportunity not just for feedback on direction but for positive feedback. "Cool!" the product owner will say when they see something working (even partially), and cool the developer will feel hearing that. Will developers respond to that kind of thing. Are developers human? It’s in our nature.

It’s still under discussion but I’ll push for fixed-length sprints, the shorter the better. It seems to me the chief value in Scrum is the visibility that frequent check-ins afford, facilitating accountability, course corrections, rhythm and morale-boosting attaboys. I’ll let you all know how it goes as we dig in.

Next time I will try to write a bit about coordinating sprints and releases for an Agile project with the longer release cycle of an underlying platform.