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?
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.
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.
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:
- Reduce your forecast to reflect the limited capacity available for the Sprint.
- Move the Sprint Review and Retrospective up within the current Sprint.
- Explain the impact of the holidays on capacity to your stakeholders during the Sprint Review.
- 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:
- Following common practices learned through trial-and-error by experienced practitioners.
- 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.
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.