Some team members just wait until the stories they are most likely to work on will be discussed and only then they participate. Otherwise they just play with their phone and don't listen.
In some way I understand this position. Why listen to a discussion about a feature you are unlikely to help develop in the Sprint or ever?
What do you think we should do?
Stop code ownership. Make it equally likely for anyone in a team to work on any given task.
There will almost certainly be some kick-back on that, because developers get comfortable with a specific area of code, and with other people not looking over their shoulders. Also, management will see a problem with work taking longer than it might normally, because there's always a learning curve.
But it really is in everyone's best interests. Being indispensable is a two-edged sword. It starts becoming more difficult to get time off, in the evening, at weekends or to take holidays. And code-ownership is bad for a company because, when someone leaves, it costs more time than you've ever saved on small bits of knowledge transfer.
Do you invite the right people to your meetings? If you've split the system into areas of responsibility for subteams, why invite all subteams to every meeting?
For example if you have a frontend team, and a backend team, keep the planning sessions for frontend work to members of the frontend team. Maybe invite someone from the backend team as a liaison in case a task crosses team boundaries (but if that happens frequently, you may wish to reevaluate the split of responsibilities between your teams).
Ideally everyone should work on everything, but in reality that's often not practical unless your system is really small and simple, resulting in everyone knowing every part of it thoroughly. In practice of course many systems are large enough that to expect every member of your organisation to have enough knowledge of a planned task to be able to give valid input during planning sessions (let alone be equally productive working on every part of the system) is just not realistic.
Their disinterest is just a symptom. The problem is you're not distributing work evenly to all your team members. Ideally every team member should be picking up any new ticket not restricted to certain project areas.
Sounds like a motivational problem - why don't some people care about the project they're working on? Maybe its because the team is split into the 'organisers' and the 'left outs'.
So involve everyone, instead of 1 or 2 people taking charge of the planning sessions, you engage everyone - make different people take charge of each session, preferably make different people take charge during the session. Rotate it all around. I know this can seem difficult because there's always someone who wants to fuss about and organise everybody but they are the problem here.
Here's an idea: when planning choose a person at random to take charge of each story. At random. Record who was responsible for the planning of it too, so next sprint you can tell if they did a good job of getting a good consensus of estimates and task split. That'll make them pay attention, and will also give them a reason to engage with the project.
Remember, the problem isn't them, its you and the way your planning sessions are done. So when someone else takes over a story plan, they get to chose how to go about it there should be official way of proceeding. (ie don't sit back and continue to force your organisation upon them by proxy)
What is your sprint duration?
Longer sprint durations lead to
So if if your sprint duration is more than two weeks, try working in shorter sprints.
If it is difficult to get the stakeholders to commit to shorter sprints, then you could skip some of the formal meetings, e.g. only have the sprint review after every 2 sprints, instead of after every sprint.
