[dale_glass]

When I was doing the scrum master role I just did sprints flexibly.

It's not a law of the universe that there's got to be a sprint every 2 weeks. For instance I'd schedule them around holidays and vacations. Try to make sure for instance that the next sprint planning coincides with a team member returning from vacation. That way they're in the loop about where things are at, and we don't make a plan based on some assumption of what Bob might do when he returns mid-sprint without him being there.

Overall I think sprints are a fine idea, projects can be complex, it makes sense to me to periodically sit down and figure out if we're getting there or not and what the next steps are. We'd also try to have demos each sprint to make sure that something actually works.

[nix-zarathustra]

Flexible sprint durations defeats the purpose of sprints. One of the main selling points of sprints is having a fixed time period of work, allowing teams to better understand the amount of story points they can complete in a sprint. This way, a big piece of work that takes 500 story points can predictably be completed in 2½ sprints if it takes a team 200 story points per sprint.

[dale_glass]

True, but that's the theory, and there's the practical reality that is messy. Where things like almost the entire team being on vacation for Christmas happens. Or where Bob, coming back from vacation 2 days into a new sprint would find out that everyone made a plan without him being involved.

In such situations something's got to give. My choice is that the something is the rigid process. Because I think it's much preferable to make a plan with the whole team present.

It's not that big of a deal really. Flexibility doesn't mean we're always picking random sprint lengths, it means we make occasional concessions for real world constraints, which is kind of the point of Agile anyway.