New PBIs are evolving

every item added to Product Backlog is complex

Can you split the PBIs into smaller PBIs? This is a common technique and allows you to deliver value to the business sooner and easier.

product owner and stakeholders they are pushing the team to be more productive so the goal of product can be done on the deadlines.

Can you explain to the Product Owner that pushing the team to be more productive won't work, and if they want value sooner, then helping clarify the PBIs will be helpful?

Also, with Scrum, the time, cost, and quality are fixed, but the scope is flexible. If the business has a "deadline", then the team should be able to deliver something by then. But what that something is will need to be worked out with the Product Owner - which is the purpose of PBIs.

Increase the team capabilities by adding new people to Dev Team. 

How big is your team now? Generally, adding more people to a team beyond a certain size won't improve their "productivity".

Have you asked the development team what they think?

Some people are data driven, Therefore, one more solution would be to ask PO for a refinement during which DT would roughly estimate all work remaining. Based on previous velocity it could then be demonstrated that the deadline is not realistic, so PO has data to work on with stakeholders in order to align on a new, realistic plan.

How are the conversation in during the Sprint Review? This is the perfect moment where everybody involved is engaged to inspect the increment and adapt the backlog. Ofcourse stakeholders consistently want more, and everything has to be done yesterday. But there are things that need to be done the day before yesterday. 

What I'm saying is; try to find the stuff that REALLY needs to be done to achieve the goal or the vision the PO has for the product. Coach the PO that he/she should act as filter between the stakeholders and the Dev Team. This also means that not every they want, can actually be done. Or maybe it doesn't even really contribute to the vision. 

Story mapping is nice practice that would help here, based on the limited information provided. Define the flow of the product, create the stories that fit, map them according to releases.

Also, during the review, you as a Scrum Master can facilitate the discuss with everyone present that the team feels pressured. What are the effects of this? Is quality going up or going down? Are stakeholders actually getting what they want sooner or later? Etc. etc.

Sounds like your PO and stakeholders have read many of those articles that say agile makes you faster.  It can make you faster but only if the organization is willing to make changes. One of those changes it the willingness to constantly adapt the work that is asked for based upon stakeholder feedback on the work that has already been done. It will allow the faster delivery of value but incrementally while adapting to changes. How many times during your reviews have the stakeholders changed what they are asking for?  If they can change their requests, then the organization should be able to adapt to the requests.  Sometimes it may make it possible to deliver faster but it can also require additional time.  Agile is not about delivering something on a deadline. It is about delivering the right thing needed by the stakeholders incrementally so that you can adjust how you get there and in some cases where you are going. In today's world economy and technology changes frequently and fast. If a stakeholder asks for ABC today and wants it in 12 weeks, there is a very good possibility that ABC will no longer be needed at the end of the 12 weeks and ABR is needed instead. Scrum is designed to help in the inspect/adapt feedback.  

As to adding additional team members I would enter that very cautiously.  As @Ben said, putting more hands on a task does not always make it faster.  In fact, if you add people to a team it has the potential to put that team back into the Storming phase (search for Tuckman's stages of team development).  That is usually disruptive and leads to a lowering of the teams performance as they learn to work together all over again. 

now the team is complaining since new PBIs requires more time than what they have progressed before. 

Maybe I am missing something, but I'm struggling to see why this is an issue.   Isn't the Development Team refining items with the PO?   To that point, doesn't the Development Team have a say around the size of PBI's?   Smaller items are certainly more desirable, but is there really an issue if a Development Team has a velocity of 20 (for example), and they accept 4 items at 5 points each, as opposed to 10 items at 2 points each?

But product owner and stakeholders they are pushing the team to be more productive so the goal of product can be done on the deadlines.

Saleh, as a Scrum Master, especially one with a PSM II certification, why are you not educating the business around such destructive practices?

Per the Scrum Guide:

The Development Team works to forecast the functionality that will be developed during the Sprint... Only the Development Team can assess what it can accomplish over the upcoming Sprint.

How does the practice of "pushing" work to the Development Team adhere to the above Scrum Guide excerpt?

And regarding the two suggestions you made to help remedy the situation, I have the following observations:

• Has the Development Team stated they think they would be better positioned to meet business objectives if their team were augmented with additional skill sets?   If not, why would you propose an increase in team size would help the situation, when all empirical data suggests that the addition of team members mid-project actually slows down progress?
• What empirical evidence do you have that indicates a change in sprint length is tied to an increase in productivity?

The "conflict" between business and developers regarding what is achievable over a given time period has been around as long as IT has existed.   What has been learned and understood during that time is that "estimates" (and subsequently timelines and release points) are only valid if they originate from those doing the work.   Work with the business to help them recognize what is truly achievable.

Good luck! 

The conflict still with the product owner and Stakeholders about deadlines!

There is a deadline at the end of each and every Sprint when a valuable and usable increment must be delivered.

Why isn’t the Product Owner able to order the Product Backlog so the team’s priorities represent stakeholder interests?

Thank you guys, 

Here's my update:

I facilitated a meeting yesterday with DT and PO and eventually they decided to break down the PBIs and we created a Story map in order to keep our releases based on vision, and during refiment & testing some Priority of PBIs are changed and PO has to make sure to optimize the work of DT in order to achieve the goal of Sprint.

I will facilitate a meeting with PO and stakeholders in order to remove any misconception about Scrum and Empower the DT autonomy. 

Any suggestions from you guys are helpful, and thank you 

BRs

Saleh

Thank you for the update Saleh.   I think your new approach to help mitigate the situation is excellent.

@Saleh, I wish I could add to your solution but it sounds like the perfect way to start people moving in the right direction.  Don't expect it to be easy or fast.  Remember that Scrum is based on incremental delivery of value.  That doesn't just apply to Product Backlog Items.  I have found that introducing changes in behavior is best done incrementally as well. 

Good Luck!