Told I wasn't coaching effectively for sprint planning!?

 I outlined that they were to define the sprint goal, and then take the features on the backlog and begin to flesh them out into stories

My teams typically craft the Sprint Goal after they decide what stories are going to be in the Sprint Backlog.  However that is after they have done a lot of refinement of the Product Backlog. In your case of this being the first Sprint, I think you handled that appropriately. I would have done the same thing.

I asked for clarification and they said that I need to be more assertive with engineers that are steering the team down a rabbit hole...

I am going to assume that the "they" were the engineers themselves.  In that case, my coaching would be that since the technical domain is theirs, they should police themselves on this.  At any point in those conversations, anyone that sees a rabbit hole forming should speak up to the team.  It doesn't have to be you or the Product Owner.  In fact, the two of you will most likely be the least technical individuals on the Scrum Team. There is a concept of "ELMO" that I teach my teams.  At any point that someone feels that this is Enough Let's Move On (ELMO) they can call it out. I have even seem cards, similar to planning poker, that everyone can have and hold up instead of speaking up.  That way, especially on a video conference is obvious someone is calling. If there is any dissenting vote, that individuals get a chance to explain why they feel more discussion is needed and the team basically votes again.  This has solved a lot of the rabbit hole conversations but it is coming from the people most familiar with the topic.  I have called ELMO when I recognize that the conversation is covering the same path more than once and never really had anyone object. 

Your distributed team problem is probably going to continue to be a problem if they do not understand how to attend gatherings remotely.  It takes discipline and everyone will have to cooperate. Ask your HR group if they have any type of "remote meeting etiquette" materials that they can present to the team.  If not, I know there are a lot of resources for that on the web.  You may have to do some education on this as part of your "make the team more efficient and remove impediments" job. 

Sprint Planning must be actively de-risked, and Product Backlog refinement is instrumental in achieving this. What issues did the team stumble upon which could have been anticipated and dealt with in refinement? Was the work truly “ready”? Might it be possible to reduce the time needed for planning, the chances of team members being surprised by what is asked of them, and the window of opportunity in which critical problems might occur?

Hi Jon,

1. JIRA went down right as we started, for the entire call /facepalm & people refused to go on mute:Consider this as learning experience(empiricism) and will take some time to improve. What i have experienced is whenever there is a change in Scrum master or team structure, there is some kind of friction or relentlessness in team as everyone doesn't like changes. All they need is transparency, regular updates and scrum master's support. Recently there was some restructuring in my organisation and team was restructured based on business value- same people, just different teams and scrum masters. For at-least 2 sprints, there were so many questions from all the teams on Whys and How. But now everyone is getting settled down as they got answers of their questions.

2.  I don't understand the technical side of things enough to be able to know : This is also a very common experience. What i do is i ask that team member to explain his blocker to all of us and ask other team members if they can resolve that issue. Many a times, we got the solution there itself. this taught them both self organisation and becoming cross functional. Otherwise i asked them if they know someone who can resolve it. It takes some time to build a cross functional, self organising team and scrum master has to have patience and still being supportive for achieving scrum team's confidence.

Hope this helps

Thanks for the feedback all, I agree with what was said. To clarify, the feedback came from the two directors who were listening to the planning session. One of which was consistently telling the engineers that's not the scope of this team, or we don't need to go down that route right now. Very command and control where I am.

BTW I love ELMO, totally stealing that! :)

the feedback came from the two directors who were listening to the planning session. One of which was consistently telling the engineers that's not the scope of this team

Unsure why directors would feel the need to attend a Sprint Planning session, unless they did not trust the Scrum Team to be able to conduct it effectively?   Command and control behavior is a clear sign of mistrust, BTW.

Hi Jon Joe - It typically takes a few Sprints to get it all working smoothly with a new team. 

Curious, what were the outcomes?  Did your team come up with a Sprint Goal?  A lot of teams ignore it, kudos to you for coaching them to create one.  Did they stay within the time-box?  Does the Development Team feel good that they have a forecast, and do they have enough Sprint Backlog work for the immediate few days?  At the end of planning was the Development Team able to explain to the Product Owner how they intend to meet the Sprint Goal?  Did they accomplish all of this using self-organization (asking questions of the PO, collaborating, making their own decisions)?

If so then you're on the right track.  There's always the Sprint Retrospective to course correct next time.

OK, after hearing that "they" were Directors everything makes so much sense.  Yeah, I'm a bit cynical but it comes from past experiences.  So, let me give you a second opinion on this one. 

As @Timothy stated, it appears to be a real case of mistrust, not only of the Development Team but also of the Product Owner. They do not seem to trust the Product Owner to be identifying the problems that if solved will provide the greatest value to the stakeholders and the organization.  This statement from the Scrum Guide describing the Product Owner speaks volumes about this (emphasis added by me)

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

The Directors actions goes against both of my highlighted passages. As Scrum Master you need to show the Scrum Values of courage and respect.  Talk to both of the Directors (I suggest at the same time) and explain to them how their actions are adverse to the Scrum Teams ability to provide the value for which they were formed. Explain to them how Scrum is geared towards providing the correct value at the correct time and cadence. Help them to understand that their command-control attitudes will ultimately cause Scrum to fail.  Suggest to them that they give the team a chance to come together and start to produce. Ask them to come to you if they feel that they are seeing problems and that you will work with the team to improve as that is your job.  But also remind them that you job is also to (from the Scrum Guide section on Scrum Master responsibilities to the organization)

• Leading and coaching the organization in its Scrum adoption;

Be clear that nothing you are saying is any way a statement of "you are doing it wrong" because after all, they are above you in the corporate food chain.  Ensure them that you are just trying to do the job that the company, and their portion of the management chain, felt you were most qualified to do in order to provide value to the company. Ask them to be patient with the team and see if they can start to become more productive. 

I will end by saying that none of the things I suggested above should be done in private.  The Scrum Team needs to know that you have taken these actions. Be transparent with them as it will help to build trust.  It will also let them know that there are some expectations of them. This allows them to consciously take them into account as they form as a new team. By doing this you are being a true servant-leader and help them to learn the Scrum Values by example.

Yeah, the directors are VERY command and control. They don't yet trust the teams to function self-organized. Because, they've proven they can't be trusted. We give them the autonomy and they use that to not do work... Plus the scrum teams have a very don't care attitude along with being very silo'd so if someone doesn't do their side, it's like oh okay, we need another sprint I guess... 

The teams practically ignore me at this point, because there's 0 accountability. The teams as a whole don't care, and I've literally been told they don't read their emails, or that I explain things too long winded or that I write too much and they don't want to have to read all that... 

I'm completely disrespected, and I've had to actually work on not being frustrated with the teams. I've asked the managers and directors continuously to step in and back me up, but it's not really getting done, or it gets done very half assed. 

Honestly, our issues are mostly management and personal moral.