So, I think your general approach of asking (politely!) for explanations and justifications of jargon-laden ideas is right on. There's no shame in admitting you don't know, and asking people to elaborate on their thoughts is a way to be respectful.
Some additional strategies that may supplement this generally good approach...
Keep meetings/discussions moving and on target
If you're brainstorming how to make a process more efficient, then a description of agile and backlogs is right on topic. If you're talking about new developments for your next wave of GUI development than a Modern GUI may be worth a good 10 minutes of chatting. But if your original issue was "how do we fix this bug?" - then you've gone VERY far afield with either conversation. Rather than start with a "please explain that idea you just mentioned" - you may need to back up and say "is this relevant to our current topic? No? Then let's make a note and get back to that later". That gives you time to catch up with the jargon speakers later and get a better idea, without making everyone in the discussion live through an off topic tangent.
Realize that for people with a different background, it's not a buzzword, it's a way of doing things.
The word "buzzword" tends to have a negative connotation. Many people use it to mean "trendy ideas" or "ideas that senior management things engineering should do" (with an overtone of doubt and dislike). The word "jargon" is a similarly laden word, but can be often taken to mean "specialized language spoken in a certain field that isn't general for all language users" - which is a little more open ended and less negative. Either way, these three sentences can be perceived differently:
- I don't understand that word - please explain/define
- I don't understand that jargon - please explain/define
- I don't understand that buzzword - please explain/define
- (most extreme) - What's with those buzzwords?? That makes no sense!
If you have contentious discussions, it's a time to watch your language carefully to make sure that in asking what is (in essense) a fair question that you aren't sounding like you're already prejudiced against the idea.
Ask for a bit of history or connectedness..
As other answerers have said - agile & backlog come from a set of ideas around Agile Development methodologies - a pretty widespread practice in some industries. It's a concept that is over 10 years old and has a big enough following to be called an industry practice.
Modern was a new one on me, but I'm willing to buy Mark Chapman's definition and realize that it's not a judgement call (modern = nicer, than legacy) and is rather a specific term used to describe qualities associated with a specific product.
Sometimes the question is not "please define this term" but rather - where did this idea come from and how can I learn more? It's another subtle but important nuance to asking these questions. Why and where a term came from can be a really helpful insight into whether or not it's useful in the current circumstance.
Learn how you learn and use it
As the team lead, you do need to be aware of the concepts and practices your team is raising. While getting an explanation from team members is a great place to start, you're also going to want to get your own opinion from getting outside perspective. To do this, fall back on how YOU learn, and make sure you have resources and time dedicated to keeping up with the topics. You don't have to be smarter than your team, you just have to have the ability to use their ideas as a way to help gain your own insights.
Combining your own research with follow up described below in the 1 on 1 format can be extremely powerful in a good way. Taking the time to research and learn something yourself, and then following up privately tells the person your working with:
- I trusted your ideas enough to take my own time to learn something
- I consider your research and thoughts to be worthwhile, so I'm asking you what you know
- These ideas are valuable enough that I haven't forgotten about them
- I want to give you ownership if we decide to change - please show me that you have ideas and plans on how to make your idea a reality.
If they didn't take the time to research, it must not be very important, and saying something - "I'll wait for you to get back to me with your thoughts" - pretty clearly says, "if you can't take the time to research more, then I won't justify spending more time on this."
Set a tone of "no idea is a bad idea, as long as you can explain it"
You can't move forward on empty words - just reading an article and collecting tentative ideas isn't enough. Get your team into the habit of doing research on topics that interest them and raising well-though-out points. The only thing that strikes me as amiss is that you have someone raising ideas that he can't justify with more than "I don't know what it is but I know we need it". No idea is a bad idea.. unless you don't have enough insight into what you are suggesting to back it up with some thoughts on first steps and the impact of the change (for the better and for the worse).
How to show research
I'm not a really big fan of paper writing or presentation giving in a formal sense - I find that this puts a damper on good ideas... but you want to get the team past shooting out empty words. If I'm faced with someone who knows a term but doesn't know the meaning, I generally turn that into an assignment immediate - go figure out the meaning and impact of this idea, and then let's talk offline. Given that I also love 1 on 1s, that makes a good point to follow up on casually. If I see numerous cases of the same individual throwing out concepts that aren't decently thought out - I may raise it in a more formal way of saying "look, I need more than just the word, I need to know why it matters" - this may be a more direct and forceful point of feedback when dealing with a more senior engineer. I expect junior engineers to have less well enunciated ideas, I expect senior engineers to be more eloquent and knowledgeable. I expect very senior engineers to be wiser than I am on what the impact could be to engineering processes and the time and effort required - that's a form of technical expertise that I'm looking for as people become more experienced.