Is it a good idea to conduct the Sprint Planning meeting again if client comes with new Requirements?

If the new stories are a higher importance than the one's previously planned (which it reads like they are) then I'd agree it would be wise to regroup and inspect the Sprint plan based on the new knowledge. 

What other stories, if any, would the development team now have to say no to given that additional priority stories were added to the Sprint? 

It's important to expectation set with the client so they understand the impact of adding new stories that are priority for that same Sprint. 

@Tony - Thank you for the reply.

Say initially we were having 10 Stories and now client came up with altogether 10 new stories which needs to be understood by scrum team.

In this case : 

1] Should we have Sprint Planning meeting again?

2] Should we CANCEL the existing sprint ?

I agree that in Agile we welcome changing requirements, but to this extent?

Would accepting the new 10 stories render the prior plan invalid? 

The impacts to the Sprint are going to vary depending on how far the development path you've went down. Day 1, maybe it only wastes an hour or two of the teams time. Day 7, very different impact. 

Would accepting the new 10 stories render the prior plan invalid? 

Yes, these are all together new stories.

Let me ask my question again - 

1] Should we have Sprint Planning meeting again?

2] Should we CANCEL the existing sprint ?

3] What should be SM's take on this?

If you cancel the Sprint wouldn't you have to Sprint Plan again for the new work?

If I were the Product Owner I'd want to understand the impact of my decision to scrap all of the current work in progress to take on a whole new set of stories. I'd also want to understand what led a whole new Sprint of priority work needing completed mid Sprint. 

As the Scrum Master, I'd want to make sure the conversation between the PO and Dev team happens so that the team can decide the best path forward...scrap the Sprint and start over or finish the current Sprint if the functionality being worked on is still valuable and take on these new priority stories later. 

I find it unlikely 10 stories showed up out of the blue that are so important (and can't wait a week or two) that the team can't finish the rest of their existing work in progress. 

Client (Product Manager) attended the Sprint Planning meeting with us today and at EOD (End Of the Day) he emailed us that new User Stories need to worked upon by the team and he wants them to be done by the end of the sprint.

@SUMIT AGRAWAL, Is the client expecting the original stories to be completed along with the additional 10 new stories?

Would accepting the new 10 stories render the prior plan invalid?

The short answer to this question is MAYBE NOT, BUT it should not endanger the Sprint Goal. However, It would be nice if you could provide more info to the first question I asked and also to provide some details on the capacity of the team to take on new work.

Client (Product Manager) attended the Sprint Planning meeting with us today

Where was the Product Owner?

and at EOD (End Of the Day) he emailed us that new User Stories need to worked upon by the team and he wants them to be done by the end of the sprint.

What about the Sprint Goal agreed between the Product Owner and the Development Team? Does the Product Owner still consider the Goal to be viable?

Say initially we were having 10 Stories and now client came up with altogether 10 new stories which needs to be understood by scrum team.

Sumit, I think this is a key here.   Assuming that the client / Product Manager / Product Owner are all the same person, I believe there are a couple key clarification questions that need to be answered:

1. Considering these additional 10 items are new and have not been refined by the Development Team, what is the Product Manager basing their belief that these 10 brand new items can be completed by the Development Team within the next sprint?
2. Is the Product Manager willing to exchange the original 10 sprint items that the Development Team forecast for completion by the end of the sprint, for a brand new set of 10 items that will both render the original forecast null and void, and introduce a significant amount of risk around the Development Team's ability to deliver the new 10 items?

@Steve - Is the client expecting the original stories to be completed along with the additional 10 new stories?

No, client is not expecting original stories to be completed. Instead of that he asked for new set of stories to be done.

@Timothy - Considering these additional 10 items are new and have not been refined by the Development Team, what is the Product Manager basing their belief that these 10 brand new items can be completed by the Development Team within the next sprint?

I am not sure on what basis he is expecting these new 10 replaced items to be delivered.

And its sounding more like an order rather than request to me. He is bit difficult guy to deal with.

@Sumit It looks like your team need some really strong leadership. These kind of re-prioritization will have many unforeseen impact like:

• Development team gets demotivated, they will soon pickup that leadership is not good in the team
• As as a servant leader you should try to shield team from outside bad influence of stakeholders.
• You should focus on transparency - ask the 'difficult guy' the need of the new requirement that cannot wait till end of the ongoing sprint and what was it that these requirements were not known at planning meeting.

Agile methodologies help in dealing with such difficult guys specially if they are coming from traditional project management

Thank you everyone for sharing your views / suggestions.

To conclude - 

We will CANCEL the current sprint and do Sprint Planning AGAIN on next day.

As the Scrum Master, I will make sure the conversation between the PO and Dev team happens so that the team can decide the best path forward.

We will CANCEL the current sprint and do Sprint Planning AGAIN on next day.

Sumit, that is one approach, but as their Scrum Master, it is imperative that you make visible the risk and consequences of the Product Manager's actions:

• After only one day, the Product Manager changed their mind on what they wanted the Development Team to work on.   It is important that the Product Manager understand that their indecision reduced the capacity of the Development Team for the current sprint (re-planning, refinement of new items)
  
   
• Lean waste was created through work the Development Team did for the original 10 items.   Context-switching through this 180-degree pivot introduced at the beginning of the sprint will also sap more capacity from the Development Team
  
   
• You mentioned that the Product Manager has an expectation that the Development Team will be able to complete 10 brand-new items by the end of the sprint, yet the Product Manager is not basing this expectation on anything other than what they would like to happen.   Make it perfectly clear that this expectation is not supported by any empirical evidence.   
  
  
  
  Wishful thinking is a poor approach for any type of planning, and it is inherently unfair to set an expectation of delivery for work that hasn't even been identified by those selected to do the work
  
   

What can you do to help your Product Manager better understand not only the benefits of Scrum, but also the negative aspects of his current approach?