Dynamic length of sprints in Scrum

Question

I have been working several projects with Scrum method and, in some, we have taken the decision of execute Scrum sprints of dynamic length (every sprint).

For me it have some advantages:

• Adapt the Sprint length to the "real" work charge by Sprint (always respecting the Sprint min-max duration rules).
• More simple planification of Sprint (not have to "play with" the end of the Sprint to fix the lenght)
• Easy to adapt complete functionalities in short planifications.

The main dis-advantage is that feedback to the client is sent in variable time spaces, but if they are informed and confortable with this, there are no problem.

Is this an accepted practice in the Scrum method?

--update

I have posted the same question in the official Scrum Forum and, as we can see, no quorum: http://www.scrum.org/Forums/aft/340

Answer 1

One of the primary reasons for the fixed sprint length in Scrum is to make obvious various problems your team(s) might be encountering. Removing the regular cadence will make it more difficult to see these problems and address them. For example: if you consistently have trouble completing functionality within a timebox, that may be a sign that you are not breaking stories down enough. OR, it may mean that something is wrong with your testing process (happening too late in your process, is not sufficiently automated, etc).

Another good reason for a fixed sprint length is when you try to scale Scrum beyond one team (don't know if this does or will apply to you). It is much easier if all your related teams are on the same cadence.

Also, I would recommend googling the "importance of agile cadence". There are a number of articles on the usefulness of cadence beyond just velocity.

Finally, there are some situations where a fixed development cadence just doesn't work well. That may be the case for your situation. I would recommend looking into Kanban as an alternative to Scrum (it doesn't use iterations at all, but implements many of the same agile principles as Scrum).

Answer 2

Scrum is a framework with few constraints; one of them is the timebox Sprint with a static rhythm. You need a static length of sprints to calculate your velocity, and to use the scrum pattern "Yesterday's Weather" in your plans. You have to make your team to get into the habit of doing scrum ceremonials that's why the rhythm of the meeting must be fixed and predictable.

Answer 3

TL;DR

No. Scrum is based on time-boxed iterations, and one of the main tenets of the framework is that the Scrum Team accepts work into the Sprint based on how much work can fit within a fixed-length Sprint rather than sizing the Sprint to fit a given volume of work.

More to Think About

While it is acceptable to adjust the Sprint length to fit the Scrum Team's needs, that is a allowing for adaptation of process rather than indicating that it's okay to have variable Sprint lengths. Continuously-varying Sprint lengths is a project smell that indicates that work may be:

1. Improperly-sized, rather than composed of small done/not-done chunks.
2. Assigned from outside the team, driving a requirement to finish X amount of work in a given Sprint.
3. Improperly prioritized on the Product Backlog.
4. Insufficiently granular to make a good user story.
5. Too tightly-coupled with other user stories, often indicating a missing user story or a poorly-defined epic.

There could certainly be other reasons, too, but these are a good starting point to try to figure out why you feel like standardized time-boxes are a bad fit for your group.

Scrum-Like Isn't Scrum

If you use continuously-varying Sprint lengths, you are not following Scrum. You are possibly doing something Scrum-like, and potentially something agile, but as a Scrum practitioner I wouldn't take either for granted. Scrum requires time-boxes; if you don't use time-boxing, you aren't doing Scrum.

If time-boxes with hard cut-offs are legitimately a bad fit for your work-flow, you might consider other agile frameworks that focus on different mechanics for managing iterations, cycles, and throughput. However, you should certainly make sure you understand why fixed-length iterations are a bad fit before you try to replace your methodology, or you may find yourself with a different (but still poorly-fitted) methodology for your process.

Answer 4

Adding to already proposed answers I would recommend this short read: http://www.agileadvice.com/2013/05/15/referenceinformation/the-rules-of-scrum-every-sprint-is-the-same-length/?utm_source=feedly

Looking at my experience, dynamic length of Sprint was really bad idea. It not only removes sense of rhythm, but in case of work being done actually earlier than planned shrinking time for Sprint removes possibility to introduce Slack which is crucial to allow team self-improve. Good blog post on importance of slack by Paweł Brodzinski: http://brodzinski.com/2012/11/wip-limits-pull-slack-bottlenecks-explained.html