Skip to main content

Is it possible to suspend next spritn start for a while

Last post 08:07 pm January 2, 2018 by Ian Mitchell
11 replies
08:57 pm December 18, 2017


I have a question for you, as it is in the title. But maybe some prelude first.

Few days ago, I've talked with my friend about his project. He told me, that because of Xmas and some team members holidays, they decided to suspend next sprint start for new year. They have 2 weeks sprints. He also told me, that other way they can have 3 days spirnt (according to Xmas). They want to have full time sprint, so they'll start in the new year.

I told, that in my opinion they should start 3 days sprint, and plan less tasks.

Who had rigth in this case ?

09:07 pm December 18, 2017

How does the Scrum Team believe they can use the 3 days most effectively, considering the people and time available?

09:22 pm December 18, 2017

Frankly, I dont know - And probably it’s my mistake in this case. I’ve only based on scrum guide - next sprint starting immediately after previous sprint conclusions. 

04:01 pm December 19, 2017

Hi Marcin - 

If you follow the exact letter of Scrum, then the next sprint should start immediately after the last sprint ends.  However, in most of the teams that I work with, the last week or so of 2017 provides a similar situation.  Most teams have decided to delay the start of the next sprint until the first week of 2018. 

We actually found, in this case, the delay allows a 2-week sprint schedule to better fit into the 2018 calendar.  We use the time (about 3 days) for a version of "Fed Ex days" to allow Developers to work on a non-product independent project. 

It's really going to come down to the trade-offs for your team.  Skipping the "fuzzy" time at the end of the year does create more consistent sprints, but does go against Scrum guidance. 

I think the more important thing is that if whatever your team decides to do this year doesn't work, don't try the same thing again next year.            


06:17 pm December 19, 2017

What would be the harm in just saying this one sprint starts early and will be a 3 week sprint instead of the normal 2 week sprint? I would rather extend 1 sprint instead of creating a wholly separate 3 day sprint, but that's just me.

I also like what Brian pointed out, they could use these days for working on other issues that can be completed. As a scrum team, you want to provide a sense of value so if it comes down to the team does absolutely nothing for 3 days; what benefit is that to the organization and what value does that contribute? That's why I would go with the FedEx days like Brian mentioned or just start the next sprint early and have it run for 3 weeks, those dev team members that are in the office will work on what they can until after the new year when things are back to normal.


06:56 pm December 19, 2017


thank you Brian and Curtis for your answers. Imust say, that all answers gave me a lot of tips. I must say, that Fed Ex days is something new for me (and for companies which I worked), but I've red about it, and sounds great :) 

Option with 3 weeks sprint is the most satisfying for me. And I think, that it won't be against Ian answer :)

Again, thank you all for great answers.  

08:21 pm December 19, 2017

You're welcome Marcin!   

10:48 pm December 19, 2017

so if it comes down to the team does absolutely nothing for 3 days; what benefit is that to the organization and what value does that contribute? 


I guess the real question there is, how much do you trust the team to be productive if they are allowed to select what they work on?

Mike Cohn came up with an interesting idea a while ago to schedule blocks of sprints for 12 weeks (6 2-week, 4 3-week, etc.), and then allow the 13th week to be a free week for whatever the team decided.   They could work on tech debt, they could refine stories, they could spend the time learning or cross-training, the key is it would be left to them to decide.

This approach appealed to me because it fit into a corporate "quarterly" cycle, and that 13th week took care of issues like end-of year.

02:34 pm December 20, 2017

Timothy, That's a cool idea as well. My point was more targeted at IF (which is rarely the case) the team had no technical debt and there was work to be done that would provide value to the company. Typically, there is always work to be done but depending on the team and the company, there truly may not be anything for the dev team members to do. 

02:16 pm January 2, 2018


in the Scrum Guide is not written when the sprint planning has to start. My solution would be:

As long the Product Owner trusts the Developement team to work on some technical debt or improve their skills f.e. I don't see any problems with Fed Ex days, Trainings, etc during the Sprint. The Developement Team should make their results of course transparent.

So offically the lenght of the sprint would be three days and two weeks with a Sprint Planning after the three days.

Happy new year!





07:21 pm January 2, 2018

in the Scrum Guide is not written when the sprint planning has to start. 

Nils, I believe the Scrum Guide is fairly explicit about when Sprint Planning must occur.   If you read the guide closely, Sprint Planning is a precursor to the start of a sprint - basically, you cannot "sprint" without first completing Sprint Planning.   Therefore, your proposed solution of conducting Sprint Planning 3 days into the sprint runs counter to Scrum.

Also, from The Scrum Guide:

Sprints have consistent durations throughout a development effort. 

It not only runs counter to Scrum to introduce varying sprint lengths (i.e. - 2 weeks and 3 days), but it is wasteful from a Lean perspective (introducing variability).

08:07 pm January 2, 2018

If Sprint Planning happens 3 days into the Sprint, then there will be no Sprint Backlog for those 3 days. There will be reduced or no transparency over the amount of work that is thought to remain.

Transparency over the work performed by a team during a Sprint ought to be established immediately, irrespective of the nature of that work and whatever relationship it may have to product development.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.