Attendance and Availability during Sprint Events

With the given context preferable option I would have taken. 

1. During our earlier sprint planning we would be knowing the available day for sprint and adjust the sprint backlog to be completed before a day than actual sprint end date(as per rhythm). Though it's a day less for team 2 its better not loose  70% team members in next sprint planning .   Synchronisation within team for next sprint is very essential 

2. Other option normally when any emergency leaves team members having during ceremony is, offline bring them to the context , contribute and understand the next sprint goal activity 

I'm currently handling a distributed team with different time zones and my dilemma right now is about the schedule.

Why is this your dilemma? Is event scheduling something which the team are unable to self-organize for themselves?

My advice is to facilitate an activity in which the team decide what is best to do.

In addition to Ian above, might I suggest to use Liberating Structures 1-2-4-All in this case? This one lends itself perfectly and you'll be surprised what comes up in just a short amount of time..

@Ian and @Sander are correct and stole my answer.  But as usual, let me give a little supporting information.

Scrum Guide states that a Scrum Master's service to the PO and Dev Team is (emphasis by me)

• Facilitating Scrum events as requested or needed.

The guide also states this as a Scrum Master's Service to the Development Team

• Coaching the Development Team in self-organization and cross-functionality;

Going to Merriam-Webster gives this definition of facilitate

to make easier : help bring about

Substitute that definition into the Scrum Guide's service statement becomes

To make easier, help bring about Scrum events as requested or needed

Helping the team decide what to do in this case is absolutely helping to bring about while also helping the team to become self-organizing.  Don't confuse facilitating for being the one responsible for doing.  Let the team decide what to do and then help it happen.  Don't tell the team what to do.  You might be surprised by the solutions that they can come up with.  After all, they are the ones that are committed to the same goals, trust each other to do the right thing and respect each other's abilities.  (See what I did there?  :-) )

If we will adjust the day to the next day where everyone is available, what will the other team do since they technically still have to report to work?

Are the team unable to make the best of this situation? If they don't see how they can add any value, perhaps there is a bigger impediment to them working effectively.

If the rest of the team really can't do anything meaningful without their colleagues, what is the point of asking them to come to work on that day?

Also, I noticed you referred to part of the team as "the other team"? I don't want to read too much into that, because I know it can be hard to find the right words to describe this configuration, but you might want to explore whether you and the rest of the team see it as one team, or multiple teams, or teams within teams.

----

In answer to your scheduling dilemma, I would focus on the option that allows the team to continue to work most effectively. The answer will depend on your circumstances, so I cannot tell you. You're certainly thinking about some of the right things.

It might be more effective for the team to wait a day and have these events together, rather than focus on utilizing the time, which could lead to a large part of the team being out of context, or feeling like they have too little influence over what they're doing.

It could be that those who are working, use the day for things like bug fixing, writing documentation, repaying technical debt, studying, sharing knowledge with other colleagues, product discovery, or backlog refinement. Although for some of those, it still may be more effective to not do them when part of the team is missing.

This one's pretty old, but I guess I still want to learn this.

I guess this is not just my dilemma, nor a problem I want to solve on my own.

I just wanted to see what good options do we have given the situation. When Scrum Teams realize issues like this, one thing they do is to ask the Scrum Master what his opinion is and a Scrum Master, I want to give them a sound suggestion but not a directive to do as I say.

@Clint John Cabunilas,  This is where your skills as a facilitator come in.  I have been in similar situations where I was asked for my opinion or advice.  I am never without an opinion so I freely give it.  But make it VERY clear that it is just an opinion and not a answer.  Explain to them how you came to that opinion making sure to provide as much background information as you can.  Then use your opinion as a lead in to a discussion.  The self-organized, self-managed team should come together on what works best for them.  I encourage that we "try this and discuss it later".  Find something that everyone will agree to try and then discuss it at the next retrospective.  Notice I didn't say "something that everyone will agree is right".  You can never know if something is right until you put it into practice.  Try, inspect, adapt.

You are a member of the Scrum Team so you should have an opinion.  Just like all of us commenting in this forum.  We all have opinions but no one has the correct answer.

If we will adjust the day to the next day where everyone is available, what will the other team do since they technically still have to report to work?

Is there a lack of trust with team members being able to "work" without explicit direction?



And I agree with Simon's observation that the labels being used (other team) can be harmful.   It is wise to use every opportunity to refer specifically to Scrum roles: Development Team, Product Owner, and Scrum Master.

I mean the really easy answer for the folks that are not on holiday: work on technical debt. Ultimately, go to the team and encourage them to self-organize. Give your opinion but ensure that the team knows that you are not the deciding factor in all of this.

Curtis Slough that's true. People can work with some technical debts but if for example we've done the Retrospective yesterday since today is a holiday for the other office, does the technical debt they will be working on becomes a part of the new Sprint or the last Sprint?

does the technical debt they will be working on becomes a part of the new Sprint or the last Sprint?

Does all of the Development Team work need to be assigned to a sprint?   

I know SAFe is not Scrum, but they have a practice where there is an "Innovation Iteration" between Program Increments (usually 4-sprint efforts) where the Development Team and PO prepare for the next PI (refinement, planning), and Development Team members are trusted to work on or run experiments on anything they feel is important, like technical debt.

From a Scrum event "order", the current sprint ends after the Sprint Retrospective, and the next sprint begins with Sprint Planning.   If there is a gap between these two events, I would simply suggest to manage any work done during that period however you see fit.   There is no right or wrong approach.

I'm going to say something that I have told many of my teams that have distributed team members.  

If you are not present for an event/discussion/decision for what ever reason you should trust that the other people in your team are going to be making the right decision based on the information that they have at their disposal. If someone is absent and you are present you should use what you know about those individuals to influence your decisions so that you are not doing things that you know your other team members will not be willing to support.  Everything you do is to make the team successful. If you start to intentionally take advantage of someone being absent, you have no right to complain if they do the same.  Treat others as you would want them to treat you. So if one part of the team is on vacation/holiday/natural disaster (yeah it happened once) they will expect that you are doing what is the best for the team just as you would expect them to do if the situation was reversed.

Coach your coach to do what is right for the team, the product, the organization for which they work and don't try to get too hung up on rules or "what is right".  Do what is right for now given the current information/circumstances.