Agile – Some team members don’t actively participate in Sprint planning

I think there are two aspects to answer your question, but let me start with congratulating you for working with people who seem to be smart and competent enough to be able to pretty much work without a strongly defined process and still deliver a product. Unfortunately this isn't a case in all software teams, so maybe one of your issues with Scrum might be that you and your co-workers actually don't need a process dumped onto you to make you more effective. You might already be effective.

Other teams aren't and need a more strictly defined process and some guidelines to get them to get things done. This doesn't mean that these teams are more stupid or less capable, it just means that maybe they have problems self-organizing or working with discipline as a team. This can also be a simple learning experience when coming from a place where people work mostly alone to working together as a team. Scrum can help getting there, because it offers a few guidelines that are both easy enough to understand and follow, yet effective enough to put some pressure on the team to start getting it together.

Since Scrum doesn't say anything about the way that software development should be done it also leaves the team with the freedom to decide for themselves (e.g. you can still do a sprint applying a rather conservative waterfall method as long as you are done at the end of the sprint).

So the team is one issue. The other issue is management and management trust. Here, Scrum might be good because it's transparent and allows any stakeholders to see the progress the team makes in defined cycles. So it's not "we're making progress, unfortunately we can't show you anything right now, but believe us, we'll be done on time". This may be even true, but it can be reassuring for any managers to actually have a regular demo where they can see that progress has indeed happened.

Scrum is not a silver bullet. It may not work for some teams for a variety of reasons, maybe for some teams self-organization doesn't work out. Maybe for you it's the other way and it seems like a process dumped on an already productive and organized team.

When in doubt I would pretty much suggest you just try it and see. If it doesn't work and the greater part of the team doesn't like working that way, don't do it. However, check it out for a couple of months (I say a couple of months, because the first few sprints will be awkward anyway and you need time to adjust the details) and then re-evaluate.

Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.

First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.

If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.

Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.

Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.

Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.