How to activate other Team Members on the Sprint Planning Meeting?

You are discussing the difference between Component Teams and Feature Teams.  If you search for those terms you will find a lot of information on it.  There are numerous posts in the community here where it is discussed. And I have seen it discussed on a number of the reputable Scrum sites.

I'm not going to go into great detail because there is so much already available.  But I will say that in my experience, Feature Teams tend to provide much faster time to value than Component Teams.  Component Teams will inherently introduce dependencies.  However, not all companies can organize into Feature Teams.  So I suggest reading up on it and then help your company make the right decisions.

Hey - thank's for the feedback - I will search for Component and Feature teams discussions.

I just wanted to add that in fact we realise Feature Teams - but for me it does not mean that everyone knows everything... As I wrote the guys within my one team realises functionalities from different perspectives - and here partially they "do not understand" each other - they do not have knowledge of other domain in the details which could allowe them to estimate and discuss.

Tomek

Feature teams does not mean that everyone on the team knows everything.  Remember that Scrum calls for cross-functional teams that have all the skills to deliver the needed functionality.  It also says that the teams are self-organizing.  It is quite possible for a team to have a lot of domain experts if they have a domain expert for all of the skills needed. Also, if they choose to self-organize into silo'd work it is a choice/risk that they take. In that case, you may have one or two people most familiar with the work and they will lead the sizing for the work in those domains.  The key is that if the team has chosen to self-organize in that manner, then they are also saying that they trust the domain experts to adequately size efforts in their domains. 

The situation you have is not "wrong".  It is just another way to accomplish the work. I have seen other teams that are organized in that manner and they work well.  But one thing to keep an eye on is the flow of work.  If they are slicing the stories into features, they have to make sure that they don't set themselves up for failure because the back-end takes longer than expected which causes the front-end to have to cut quality.  

There is a guide on this site called Kanban Guide for Scrum Teams.  (https://www.scrum.org/resources/kanban-guide-scrum-teams).  You might want to read it.  Introducing the Kanban board practice will actually help with the domain expert split and help you to visualize the workflow.