I always recommend to teams newly transitioning to agile that they keep every iteration the same length. This helps them learn to manage their time, and after a few iterations they'll start to get a rhythm. Hopefully, they'll learn to work incrementally, doing testing and coding concurrently as part of one development effort, so that user stories are finished throughout the iteration, and testing isn't pushed to the last day.

Our team transitioned to Scrum late in 2003, and eventually adopted most XP practices. In the years since then, we have borrowed from Lean and Kanban approaches. We do sprint planning, but we often plan enough stories for the first few days, and bring in more stories as time frees up. Over the years, we've built large suites of regression tests at all levels which run continuously and provide quick feed back. Every day we have a stable build which we could release to production if desired. We do two-week iterations, but on rare occasions, we adjust as appropriate.

Photo: Top left is the theme we needed to finish, right side is the new theme

Last sprint planning, we planned to finish up a theme we'd been working on for several sprints, and start on a new theme which we expected would take at least a whole sprint on its own. When it takes more than one sprint to develop a new feature, we usually use run-time properties to "hide" them from end users until they're ready to release. We only work in our main trunk, we don't branch, and this usually works fine.

Two days into this new sprint, we realized that the model needed by the new theme needed significant database and code changes that would be costly to "hide" if we released before it was finished. We proposed to the business stakeholders that we take one week to finish the theme that was almost done, release it, and then take three weeks to do the new theme. At the end of four weeks, we'd be back on our normal schedule.

The business folks were happy to get a feature they'd been waiting for a week early, and were fine with us doing a three week sprint to finish the user stories in the new theme. It's been much easier to work on the new theme, knowing that we have three weeks to finish and we don't have to keep the new functionality "hidden". We have time to clean up old, unused code and database objects, and to update all the automated tests as needed for the new theme.

Note that there's a big difference in what we're doing, and saying "Oh, we thought we'd have all the user stories in the theme done this sprint, but we're running behind, give us one more week". We had enough information to plan an out-of-the-ordinary approach to this one particular theme. We'll go back to our normal two-week sprints, but our solid foundation of development and testing practices allows us to be flexible and "think out of the box" when needed.

How does your team handle unusual situations that come up? Is it too disruptive for you to change your schedule temporarily?