The Rules of Scrum: There are no Breaks Between Sprints

Each Sprint that a Scrum Team does is an opportunity for learning through “inspect and adapt”.  If there is a break or a pause between Sprints, the Scrum Team may forget what it has learned or fail to apply that learning in a timely manner in the next Sprint.  Of course, many Scrum Teams end a Sprint before a weekend and start their next Sprint at the beginning of the next week.  This non-working break is normal and acceptable.  However, a break between Sprints during which some or all Scrum Team Members do other work is not acceptable.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

10 thoughts on “The Rules of Scrum: There are no Breaks Between Sprints”

  1. I have it disagree on this one! After doing scrum for a couple of years, we found that the teams are getting more and more effective, everybody gets better, more involved, more passionate. What happened is that people started to feel tired and burn after sprint end, always delivering wht they had signed up to in good quality. To give the “sprinters that have just crossed the finish line” some time to catch their breath, we formalized 2 days of “slack time” after each sprint where everybody can work on anything and refuel the batteries. There is a minimal 30 minute rough planning for the slack time and results/effort is accounted for on the wiki.

    1. If your solution works for you then great! It’s always good to hear about alternatives. That said, I wonder why you wouldn’t try leaving the slack inside the Sprint itself?

  2. This sounds like horrible advice to me. I have found that there should absolutely be grey space between iterations / sprints. There’s no reason for activities like iteration planning, retrospectives, etc. to take up iteration-time. My experience is that everything works better when time between iterations is reserved for those things.

    And as far as that goes, if you like the “sprint” terminology more than “iteration” then the answer is baked right into the metaphor itself. No one can Sprint -> Sprint -> Sprint -> Sprint -> … indefinitely, or they would collapse from exhaustion. And while metaphors are imperfect, it’s actually pretty close in this case. Team members need time to disengage, clear their heads, reset, and get ready for the next iteration/sprint.

  3. This can only work if things like your planning, and grooming are also time boxed into your sprint – which I found quite difficult to actually do since those activities often require a lot of analysis.

    A day or two for your ceremonies like retros and planning outside of the sprint means that you as a team dedicate your time to those activities completely and give them the attention that they deserve!

    1. I agree that those activities need focus and proper time. The idea of a “Sprint” is that it encapsulates all the activities necessary to deliver product increments. Taking breaks between Sprints to do stuff just means that the proportion of time spent within the Sprint probably needs adjustment. For example, retrospectives are given a great allocation of time within a Sprint: 3 hours for a 1-month long Sprint. Taking more time for these ceremonies is often a matter of quickly diminishing returns. That said, if what you are doing is working for you, please continue doing it! (It just might not be “Scrum”).

  4. I really couldn’t disagree more.

    We have two development teams, one does 3 x 2 week Sprints, and then takes a 2 week “break” which they spend learning (either a new language, or something else business related), doing refresher courses, doing whatever they like within context of the business, or partaking of grooming sessions. Meanwhile, the Product Owner and BA’s spend the 2 weeks planning and grooming work for the next three Sprints.

    The teams productivity is high, their moral is high, they are genuinely happy and are learning something new every 6 weeks.

    .. I’m in the other team.

    The team that doesn’t take breaks.
    The team that has 5 projects to do.
    The team whose Project Owner and BA’s have to plan for the upcoming Sprint retroactively because they don’t have time to plan further than that.
    The team that is overworked.
    Tired.
    Utterly exhausted.
    And still expected to spend our personal time studying for the company’s benefit.

    *Everything* is stuffed into a two week sprint, and we just go from one sprint to the next without breaks.

    Our productivity is lower, our morale is scraping the bottom of the barrel, we don’t learn anything, our project has old code we need to upgrade but can’t as we don’t have time and we are not remotely happy.

    It’s not practical, feasible or has any kind of real concern or consideration for the physical and mental well-being of the developer.
    We can’t keep going, and going, and going.
    We are not machines.

    Luckily we’ve put in a complaint, it’s been heard and management is looking at a way to help us out.

    Sorry for the wall of text. 😛

    1. Hey Sebastien! This is a great example of two different ways of getting Scrum wrong. The idea of no breaks between Speints is to find a way to make Sprints sustainable. In the case of your first example, by including all the PD work within the planning for each Sprint. This could be done easily by recognizing the authority of the development team to choose how much Work to take on each Sprint. Same for the team you are on; clearly management hasn’t embraced empowering your team to create a sustainable environment. I’m sorry to hear about your situation, but that’s not Scrum. What you have described is “Dark Scrum” and it is truly awful! I really hope you are able to make things better.

    2. Hi Mishkin,

      Thanks for the response.

      I’m reading up on Dark Scrum from an article by Ron Jefferies. In it, he mentions “We get to tell them how to improve …” and provides an example of a scenario between developers and power holders and that’s exactly how the power holders behave here.

      In addition, our Kanban board is basically just a really large timesheet which management uses to micromanage. There’s no self organisation; with our grooming basically being the team lead and the PO divvying out work.

      I know they mean well, but I think they’ve got the wrong end of the stick here so I’m trying to improve my knowledge so I can bring them the right info so we can do it right.

Leave a Reply

Your email address will not be published. Required fields are marked *