Sprint 1 starts November 5th and is supposed to end on November 16th, but there is a government holiday November 13-15. Can I change the Sprint 1 schedule to be November 5th to November 21st?

  • 1
    The question tags have been updated to reflect that this question is about mandated Scrum meetings. If you're not doing Scrum despite the tags and nomenclature on the original question, please edit your post to avoid confusion.
    – Todd A. Jacobs
    Nov 22, 2017 at 18:33
  • I added my comment as an answer as Venture suggested.
    – Muhammad
    Nov 22, 2017 at 18:38

6 Answers 6


Bart is correct, Sprints are supposed to be fixed length and not vary from sprint to sprint. If you are constantly changing durations, you can't get into a good cadence and that's key to effective Scrum.

When you have a holiday in a sprint instead of extending the sprint, you just recognize that you do not have as much capacity in this sprint. You take this into account when doing sprint planning. For example, if you're average velocity is 100 and you have two days of holiday in your ten-day sprint, then you only have 80% of your days. So you would multiply your velocity by 80% for a sprint capacity of 80 points.

The only area where holidays cause issues is if you Sprint start or sprint end fall on a holiday. If they do, just move the appropriate events to another day without changing the sprint duration.

Holidays is one of the main reason many coaches, including myself, recommend starting Sprints on Thursdays or Wednesdays. Most holidays fall on Mondays or Fridays so you limit the chances your major events will fall on a holiday.

  • My boss said that the pricing of this project is fixed and budgeted per sprint so we should stick on the no. of sprints estimated for this project. So if i dont adjust the length of each sprint the date will be ending soon and the capacity for each sprint will not be achieved. Nov 22, 2017 at 7:06
  • @GioLasquety: How would your boss react if it turns out that the required amount of work can only be finished within the N sprints allocated if each sprint takes 1 year? Nov 22, 2017 at 10:08
  • 3
    If your management is using a fixed scope, fixed schedule and not recognizing that estimates are just guesses, which need to be refined over time, then you won't be successful in agile. At that point, don't worry about if you're doing scrum right, you can't. Worry about if this is the right company for you. Nov 22, 2017 at 17:41

It is very much advised to have a constant length for your sprints and to have the major ceremonies (sprint planning, sprint review, retrospective) each time on the same day of the week.
This creates an easily predictable rhythm to the sprints and makes it easy to remember for everybody when they need to be available for those ceremonies.

The only reason for moving the sprint start/end to a different date should be because the normal date is a day where the majority of the participants is unavailable (national holiday, company closed, etc.).
Holidays that fall within the sprint should be accounted for with a lower availability of the development team (and as a result, less work that is predicted/planned to be finished).



In Scrum, a reliable cadence is always more important than a fixed level of productivity. Scrum is really about sustainable delivery over time, so handling perturbations in capacity is a feature of the framework.

Holidays, vacations, sick days, and early terminations are to be expected in any long-running project. These can and should be handled as minor variances in team capacity rather than as things that can derail the project's ongoing cadence.

Best Practices

For example Sprint 1 is November 5 and supposed to end on November 16 but our government announced that it will be holiday on November 13, 14, 15 so can I change the sprint schedule into November 5 to November 21?

Having 12-day Sprints is odd, but certainly allowable. If you have a three-day holiday inside the Sprint, then you should not change the length of the Sprint (because a Sprint should have a constant-sized calendar duration). However, you should certainly lower your expected capacity for the Sprint to account for the three less working days that you will have to product work within the Sprint. This is typically done during Sprint Planning so that it's handled appropriately throughout the Sprint.

Since the first or last day of your Sprint is not a holiday, you should keep your Sprint Review and Retrospective on the standard end-of-Sprint day of November 16th. However, you can certainly shift other ceremonies such as Backlog Refinement within the Sprint to accommodate the holiday if necessary.

In the event that a holiday will impact the end of your Sprint (not the case here, but it happens), you should generally:

  1. Reduce your forecast to reflect the limited capacity available for the Sprint.
  2. Move the Sprint Review and Retrospective up within the current Sprint.
  3. Explain the impact of the holidays on capacity to your stakeholders during the Sprint Review.
  4. Start your next Sprint as a normal-length Sprint immediately after the shortened Sprint.

Rules of Thumb

In general, a holiday during a Sprint will obviously impact the amount of work that can be done within the Sprint, but it need not have a major impact on the cycle of time boxes. The best practice is to encapsulate any deviation within the current time box. That means moving ceremonies within the current Sprint whenever possible, rather than extending the Sprint or moving ceremonies or work into a subsequent time box.

As Joel pointed out in a separate answer, scheduling Sprints to avoid common holidays is wise. That's not always possible, though, so simply treat holidays as reduced capacity in the same way that you would handle team members being out sick.

As long as you reduce forecasts to reduce work planned for the iteration whether you move ceremonies within or outside the time box is a trade-off. In the former case, you're simply making the impact of the holiday on your process transparent; in the latter case, you're impacting two Sprints, but possibly spreading the cost of the missed work as slightly-reduced capacity across two Sprints instead of one. I certainly recommend the former, but teams can (and sometimes do) make an argument for the latter if it's done with transparency and buy-in across the whole organization.

The amount of work done within a Sprint isn't a constant value. The time box should be as close to constant as possible, though. Over a long project, it's much better to have low-capacity or shortened Sprints due to holidays, sick team members, or early terminations that start and stop on the same days each Sprint because that supports long-term scheduling and release planning better than frequently moving the ceremonies around.

Following this advice may result in Sprints with significantly-reduced capacity, or the occasional Sprint with excessive slack or even "dead air." In general, though, the value of a reliable iteration cadence vastly outweighs the occasional bobble in capacity or productivity, and containing the variance within a single Sprint makes this variance both visible and transparent to all stakeholders.

Caveats for Philosophunculists

The Scrum Guide devotes two whole sentences to the issue of non-standard Sprints:

Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

One is forced to read into this a bit. Pragmatically, "duration" refers to calendar length, not working days or days at full capacity, because otherwise there could be no reliable cadence for use in release planning. The advice to start a new Sprint immediately after the past Sprint is based on standard iterations; the guide is silent on the issue of whether to start a foreshortened Sprint immediately after an aborted Sprint, whether to allow "dead air" or tech debt service until the next Sprint starts, or how to handle holidays or unforeseeable changes in available personnel.

People who want to appeal to authority on this issue will leave empty-handed. The best solutions to these kinds of issues are an admixture of:

  1. Following common practices learned through trial-and-error by experienced practitioners.
  2. Leveraging your own inspect-and-adapt process to find what works best for your organization's unique circumstances.

As long as your don't violate basic framework principles, anything you do that's successful for the team is, ipso facto, the right thing to do. Your mileage will therefore vary.


Yes, Holidays can be included. But the Customer/Client must be intimated about the holidays in prior.


Sprints can be of variable length, although I would advise on trying to keep the sprint length as constant as possible.

So yes, you can schedule the sprint to be however long you see fit, but I wouldn't go changing it all the time.

  • 1
    Please show me in any Agile document, guide or framework where it says Sprints can be of varied length? The only time to modify a Sprint length is running an experiment with a different cadence to see if a different timebox synchs better with your working environment. Nov 21, 2017 at 17:59
  • 2
    @RubberDuck Aborted Sprints are an edge case. The Scrum Guide is very clear that "Sprints have consistent durations throughout a development effort." There is zero ambiguity if one is claiming to follow the Scrum framework.
    – Todd A. Jacobs
    Nov 22, 2017 at 15:52
  • 1
    Ah sorry...I did not realise I wasn't in the truly hardcore Agilistis camp. Silly me for aiming for consistent, repeatable and sustainable results. Now I see the aim is "work until the thing is done". 130hr weeks for everyone! Nov 22, 2017 at 18:09
  • 1
    @RubberDuck It's tagged with "Sprint" and "Scrum Master," so I think you're splitting hairs. No other formal framework has those terms, and I can't think of a single framework that advocates variable-length iterations as such. It does a disservice to people to tell them that agile means "do whatever you like" in the name of ersatz adaptation. People can certainly be agile in other ways, but then it's not Scrum. However, if you'd like to post an agile (not Scrum) answer that supports variable-length iterations, please do. A workable alternative would add value.
    – Todd A. Jacobs
    Nov 22, 2017 at 18:30
  • 1
    I fail to see how anything can be repeatable when it is modified every week? Got any other source other than a podcast that is heavily furnished with affiliate links? Interesting you are talking about on-high when you are the one who talks about truly hardcore Agile magicians or whatever. Nov 27, 2017 at 12:44

The short answer is no. You should be able able to know about these holidays in advance and adjust the sprint backlog accordingly during sprint planning. If your average velocity is X, you can adjust it to X - (Y * number of holidays), where Y is your average daily velocity. You cannot change sprint dates because of holidays, someone falling sick or anything else. If a large chunk of committed work cannot be delivered, inform the Product Owner and I am sure the stakeholders will understand during the sprint review meeting. You achieve nothing by changing the sprint length! By extending the length, you create confusion (especially in large scale setups) and complicate velocity calculations among other things.

  • While I mostly agree with the central theme of your answer, there's a pragmatic issue that crops up when a Scrum ceremony falls on an actual holiday. For example, how will you handle a Sprint Review on any given Friday if the office is closed that day?
    – Todd A. Jacobs
    Nov 22, 2017 at 18:38
  • Again, holidays can be identified well in advance. If you learn that next Friday is a holiday and this coincides with your sprint review meeting, have the meet one day before the holiday. If, however, there is a natural disaster on Friday, have it on the first working day after things become normal. Time boxing sprints is not about arguing over an extra day.
    – Muhammad
    Nov 22, 2017 at 21:23

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.