12

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

  • Possibly related question - pm.stackexchange.com/q/605/643. Hope it helps. – M0N4K0 Apr 30 '13 at 11:55
  • I had read this thread, but my question is another. Related to base the setup Sprint length in the work inside every Sprint, and not fixed length – unairoldan Apr 30 '13 at 12:04
  • Sorry, I didn't quite get the question. – M0N4K0 Apr 30 '13 at 12:32
  • What's your variance? 1-2 weeks? Longer? – Andrew Clear May 1 '13 at 8:28
  • 1
    Not Scrum. But who cares if it isn't Scrum as long as it is working! – Andrew Clear May 3 '13 at 9:35
9

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).

  • In case of various teams, is clear to use fixed length, but is not our case – unairoldan May 1 '13 at 8:36
  • About how to address the possible problems; I do not see the difference in detect and solve this problems between fixed or dynamic approximation... – unairoldan May 1 '13 at 8:38
  • 1
    Ztere0, My comment about making it easier to detect problems is based on this: the fixed sprint length is a core aspect of Scrum. It is a very demanding practice, requiring good planning, story breakdown, estimation, WIP monitoring, testing, technical practices and communication/collaboration. By doing away with the fixed sprint length, you often set yourself up so that you A) no longer see these problems as they arise and B) are not forced to get better at them to deliver successful iterations. – Michael Ball-Marian May 1 '13 at 18:26
3

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.

  • you can perfectly calculate your sprint velocity and apply "Yesterday's Weather" just doing in a percentile mode. – unairoldan Apr 30 '13 at 12:10
  • @Ztere0 Sorry, but no. In Scrum, each User Story is "done" or "not done." Sprint Goals are either "met" or "not met." This is to avoid the "70% of our stories are 80% done" syndrome. – Todd A. Jacobs May 2 '13 at 19:55
  • I know that a history is done or not done. The percentile is applied to the total sprint, not by task – unairoldan May 3 '13 at 10:50
2

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.

  • The decision of use fixed length is derived from the necessity of finish "full functionalities" in every Sprint, to deliverable the package to the client (is his petition, only full modules). At this point, we have to decide between N fixed length sprints or "more sense" Sprint length that fit with our modules. Right now the "best reason" to use fixed length is the importance of agile cadence, but I do not see anymore – unairoldan May 1 '13 at 8:51
  • @Ztere0 The fact that you're fitting sprints to "modules" defined outside the team means the Scrum Team isn't doing the estimation, planning, or grouping of stories on the Product Backlog. This is not Scrum. Q.E.D. – Todd A. Jacobs May 1 '13 at 13:14
  • so...If the modules or user history are made in Product Backlog => not Scrum? – unairoldan May 1 '13 at 15:06
  • @Ztere0 The Product Backlog may contain a mix of stories, epics, and themes, but it is the job of the Product Owner to work with the team during Backlog Grooming to decompose items so that they can fit within a fixed-length sprint. Your problems seem to be that you are confusing release schedules with iterations, and allowing your customer to drive your internal development process. Trying to precisely align releases (as opposed to releasable increments) with iterations is not usually constructive. YMMV. – Todd A. Jacobs May 1 '13 at 22:18
  • one of the principles of Scrum is to have a potentially shippable product at the end of every Sprint. For me, it is the base of the dynamic length; maybe you can not create a shippable product at the end of every Sprint with the fix lenght (you do not have enought time...) – unairoldan May 2 '13 at 7:36
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.