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:
Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
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.
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?
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.
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!
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”).
Can’t disagree more.
Can you elaborate?
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. 😛
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.
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.
True, this is what the official Scrum guide says: ‘A new Sprint starts immediately after the conclusion of the previous Sprint.’
But on the other hand Henrik Kniberg in his book Scrum and XP from the Trenches wrote a whole chapter titled ‘Slack time between sprints’.
So, be agile and take what suits you best. In my 12 years of working with Scrum, the break between Sprints is a good thing. Call it what you will, it worked much better than without them.
This is the first result on google for ‘break between sprints” and its demonstrably wrong. There are numerous studies that show down time and learning improves morale, capability, and success.
Hi Jason, When you say “demonstrably wrong”, do you have any studies that you can reference specific to breaks between Sprints? I’d be happy to update this on that basis. However, if you read carefully what I have written, I specifically allow for down time between Sprints… So really, what this means is that the Scrum team and its members shouldn’t be doing any WORK between Sprints, but certainly can and should rest between Sprints. And the breaks should be kept short for lots of good reasons. Not only that, but to be true to the Manifesto for Agile Software Development, the team should be working at a sustainable pace which means allowances for learning time within the Sprint.
Another way of phrasing this is that the Scrum Team should only do a sustainable amount of work each Sprint. The team itself determines what that is. If some team members need vacation, time to learn something, etc., then that should be taken into account when planning a Sprint. This sustainability, unfortunately, is often not done in organizations (for lots of really bad reasons, and very few good reasons).
So in a sense, I agree with you; perhaps it is just the article that is not clear enough on what it means to take (or not take) a break between Sprints.