Changing the Sprint start day

Which violation would be least damaging to the Product Owner and his or her interest in maximizing product value?

How about ending the current sprint as scheduled, use the two days for some of the below and then start next sprint on Wednesday?

• backlog refinement
• refactoring
• bug fixing
• team lunch/dinner & movies
• process improvements
• see what else you can consider

It could be Option#2 all the way, without violating the two rules:

#1. A new sprint starts after the conclusion of past sprint immediately.

#2. A Sprint should never exceed the original timebox, though no issues in this case to conclude it a little earlier for a valid reason.

And by the way, it's a great decision to change the date for the compelling reasons you had, which is perfectly agile per my view.

I beg to differ, KP, as Option 2 isn't in agreement with what the official rules state: "Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened." It's all about consistency.

@Eugene, Agree. Keeping in view of the rule:  "A new Sprint starts immediately after the conclusion of the previous Sprint."  may be we need to see this as a special case of 'sprint cancellation'. Else I don't see any other way  of changing the Start Day without violating the rules. 

I think we should be flexible, KP. I also think the Scrum creators wouldn't be obtuse in their thoughts and not allow for adaptations.

Yes, it is absolutely true that a new sprint starts immediately after the conclusion of the previous sprint, but that's when there's a rhythm. Add a new ingredient (severe hardware failure, product development cancelled, etc)  and things change, and then you need to adapt.

This ingredient (changing the future sprint's start date) being a minor change it surely doesn't warrant current sprint's cancellation, which means it can end as scheduled. Because we shouldn't be rigid or obtuse, we can subsequently choose how to act. So allowing for two "free" days within sprints especially because it has been decided, by the team itself, it is better to change the cycle format is actually showing we can adapt to circumstances.

PS: This is actually validated, I did it with my teams, and so did many others.

allowing for two "free" days within sprints   should read    allowing for two "free" days between sprints 

Breaking the rules of Scrum has a cost, in terms of transparency, and opportunities to inspect and adapt.

But if you do decide to break the rules in this instance (which might be the best decision, and something I've previously encouraged a team to do), then it is important to make sure the impact of this change is well understood.

Progress towards the Sprint Goal, velocity measurements, opportunities to engage with stakeholders (e.g. during the Sprint Review), and the effectiveness of the Sprint Retrospective may all be impacted in some way.

It should be understood by all involved that adjusting the length of a current Sprint is a violation of Scrum, and that this action is an exception.

Simon, the discussion refers to a future sprint (and automatically, the subsequent ones), not to the current one

In the original post, Tudor suggested two options, both referring to the current Sprint.

There may be good reasons for breaking the rules in such a way, as it reduces the amount of time before corrective action can be applied.

When I recently helped a team switch from one to two weeks, and simultaneously switch the start day of our Sprint, we essentially applied option 1. We also factored in the desired day and week for having Sprint Reviews, which were not being held until that point in time, and decided that acting quickly (extending the current Sprint by 1 day), was the best course of action.

As an added bonus (but definitely not a reason I would endorse for adjusting Sprint length), the team gained extra time to achieve a Sprint Goal that would probably otherwise have been missed.

There is another option that has not been discussed. It would not break the rules, and may also have merit.

Adjust the length of the next Sprint, in order to run up until the desired end/start time.

This could involve a sprint of 2 days, or a certain number of weeks, plus 2 days.

This means that the team can account for the disruption during their Sprint Planning, and can set an appropriate forecast and Sprint Goal. Some potential drawbacks are that it delays the time before the team switch (and subsequently adjust) to their new rhythm, and it means the team will have to plan for a Sprint of an irregular length.

Unsure if this is a lot of hand-wringing over something that IMHO can be best-managed as an outlier to Scrum.

You have a one-time 2-day gap due to shifting the start of sprints from Mondays to Wednesdays.   Ask the team how they would like to utilize the time best.   No need to "adjust" sprint lengths to account for the two days - simply allow them to exist outside of Scrum.

Current sprint must end on time. As you explained the requirement of the project that starting day of sprint should be changed from Monday to Wednesday. 2 days can be utilized for backlog refinement, technical knowledge transfer, Agile coaching sessions , team bonding activities ,Celebration for success of dev team etc.  

I think my primary problem with this discussion is the statement in the original post of 

would be in direct violation of Scrum

If you will remember, Scrum is a framework and not a process.  It is a framework that supports the Agile principles. Those principles are "Transparency, inspection, adaption".  So it appears that the inspection has happened and it was determined that moving the start date was a desired change.  So I suggest you adapt the sprint start date from Monday to Wednesday and then make sure that everyone knows so that it is transparent.

Use the extra day to do some backlog refinement.  Use it to talk to stakeholders.  Use it to do an extended retrospective on how your team is working together.  Use it for a quick Scrum workshop on the values of Scrum.  

Don't be afraid to make adjustments.  That is what empirical process, the foundation of Agile and Scrum, is all about. Just be sure that you are making them for valid reasons.