I'd love to hear from more experienced agilists the considerations to use on or another method.

If you live in a country (like mine) with so many holidays, do you set the sprint size based on continued calendar days (i.e: always start on Thursdays of each week for sprints with week duration) or do you consider available workdays? (in this example, if you have a holiday on Friday, the Sprint will finish on next Thursday and the following sprint will start on Friday shifting weekday setup)

Have you tried booth? Why? Why not?

  • You haven't mentioned what country you live in or how many holidays you have, but I can't imagine you have more than one holiday per sprint, in which case you should be able to factor that into your estimates,assuming that one workday even makes that much of a difference considering your sprint length and team size. Unless the holidays significantly and unpredictably disrupt your productivity or your velocity calculations, this is one of those times where uniformity outweighs any marginal improvements in "bookkeeping" accuracy. Nitpicking about business days is not an agile mindset.
    – Pedro
    Nov 7, 2015 at 2:17
  • Hi Samuel, welcome to PMSE! Your question, as it currently stands, may be read as a polling question, which goes against the SE network purpose. I see a lot of value on your underlying question, so I'd suggest to have it a bit rephrased to avoid any bad interpretations. Cheers
    – Tiago Cardoso
    Nov 7, 2015 at 18:11

3 Answers 3


I always try and establish a fixed cadence where the iteration starts and ends on the same days of the week (tuesday/wednesday or my favorites).

Usually a mid week end date is preferable over a monday or friday. People are generally more focused mid week and it also can combat the "i'll work over the weekend (and potentially clock overtime) excuse related to not getting work done."

If there are holidays that interfere with the midweek day you know you can either move backwards or forwards by a day or 2.

The team should get proficient at adjusting their iteration commitments/forecast during planning based on variations in schedule. Is the ideal sprint duration 10 days, but this time its only 7 days due to holidays; the team should account for that in their iteration planning by shaving off a few story points or scheduling in work that is smaller in size and can still be completed by the end of the iteration.


I would try and pick the sprint start/end day to be the ones least likely to be affected by holidays. The teams I work with have tended to start on a Thursday and finish a sprint on a Wednesday. That avoids Monday/Friday which are the days most often hit by holidays (and team members working from home).

Secondly, I would stick with a calendar-based sprint. The reason for this is it allows the team to drop in to a natural cadence. It also helps when booking regular meetings with the Product Owner and stakeholders. For example, we tell the stakeholders to keep Wednesday afternoon free every fortnight for the showcase.

At every sprint planning meeting the first question I ask is what holidays are planned. This discussion includes both public and personal holidays. We almost always have some holiday to take in to account and we reflect this in the sprint capacity we plan for. For example, if the team has a velocity of 30 story points but there is a public holiday in the sprint we might only bring 27 story points in to the sprint.

  • A time is is not a sprint unless every one is the same length. Nov 18, 2015 at 20:49
  • I am arguing for a constant sprint length. What was the reason for your comment? Nov 21, 2015 at 9:23
  • I said that if it is not a consistent length then it is not a Sprint. It would be something else. So a calendar based timebox is not a sprint as each month varies in length. 30 days or less, fixed days. Nov 23, 2015 at 8:40
  • I think there may be some confusion. Both the original poster and I were using 'calendar days' to mean a consistent sprint size that starts and ends on the same days of the week. Nothing to do with months. Nov 23, 2015 at 12:50

In your organization or team, what would be simpler and yet consistent? The answer for this question will be your answer.

You must keep some rules in mind, though:

  • You have only two variables here: start/end dates and capacity. Keeping one fixed will vary the other. People likes stability, so keeping something fixed (like "every iteration starting on Tuesday, and in case of Holiday, the next business day") gives more comfort to people (after all, capacity is what dictates the amount of work to be delivered at each iteration, which is expected to vary either way).
  • You must always consider the actual capacity you have for each iteration. As capacity, I mean the amount of actual man/days you'll have for each iteration. Your planning must be based on the man/days you have. For some, here's where Story Points comes to play. Tip: Have your team Holiday's calendar at hand during your iteration planning session. I do it everytime.
  • Have your rationale to set your rules (whichever they are) in a place anyone could check. It helps new joiners to get up to speed on how you work.
  • Keep it simple. In the long run, there isn't much of a benefit of having a start date on Monday in comparison to a Wednesday. At least, I haven't seen any formal study stating so (and if there's one, please let us know!). I believe that's part of the reason you raised your question (to have some sort of feedback stating what's the best days to start / end an iteration) but I don't believe you'll have a canonical answer for this.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.