> It's a place to gently lay down bad or low priority ideas without insulting the person who filed the ticket.
I mean yes, you can use the Backlog for that, as a sort of idiot pacifier but that's basically the worst way to deal with that. Preferably you would find ways to educate those people on why their Ideas are bad or low priority so they can learn to give you better input.
> I mean yes, you can use the Backlog for that, as a sort of idiot pacifier
Again, that's really condescending. PMs will have ideas. Some will be good, some will be bad. QAs will file bugs. Some will be good. Some will be bad. The backlog reflects the bad ideas. There's nothing wrong with that. If you feel like your QAs and PMs are idiots, i.e. you're the smartest person in the room, then perhaps you're standing in the wrong room?
While I appreciate my posts being defended by other people, my intention was not to call anyone condescending. I merely wanted to suggest that any agile organisation should strive to learn from each other and find better ways to deal with bad/low priority ideas than make people feel warm and fuzzy inside while ignoring their input.
Though the use of the wording "idiot pacifier" was perhaps a bit too strong and distracted from the intended meaning.
But who is the arbiter of good ideas? This is kind of a precision / recall problem. Do you want every idea offered to be good, or do you want to get every good idea out of your team, even if that means tolerating some bad ideas? That's not to say we shouldn't strive to have better ideas overall, but the ideation process itself is valuable, even if it's unlikely to produce solely good ideas.
What is the downside of keeping the "bad" ideas around forever other than you find it annoying? My point is that people only care that the backlog grows indefinitely because it disagrees with their sense of order. This is the type of thing an analytic thinker tends to care about, but the size of the backlog queue doesn't really have any meaningful impact on anything.
I'm not sure you can say no without stifling future input, or if you can it requires a lot of tact. People don't like rejection. Being rejected makes them less likely to try again in the future.
The problem isn't keeping them, the problem is mixing them with the good ideas that are low priority. Then you have to mentally re-categorize them every time you go through the list, and if you actually start to shrink the backlog then they come back to cause problems, like making you still have to reject them or someone wasting their time implementing them.
That's obviously all context dependent and in any ideation/brainstorming process it's valuable to have a free flow of ideas but there's a necessary filtering process afterwards. David Allen writes in Detail about this in Getting Things Done, specifically in the chapters of the natural planning process.
Now with regards to the backlog, if a team can develop common criteria for high value/high priority tasks and learn to reject low value/low priority tasks than they can more effectively manage their backlog and time.
You can give feedback and use a prioritization mechanism together.
"Hey, that's really difficult right now, because ____, so we'll put it in the queue for some future time."
"I'm not sure how exactly we can do that and still <do other important thing>, because ______. It's in the queue so we can think about it later."
"Doing _______ seems to create a significant problem in ____________. Maybe there's a better way. In the queue."
This way the person doesn't need to be told an outright "no" or back down; they can save face and have time to change their mind. Similarly, the idea is preserved so that if these reasons weaken or we come up with a better idea about how to do it, we can move forward.
Finally, you preserve the concerns about the idea. Then, if you're not there when the idea is brought up again, then they can encounter it already-in-the-backlog with the concern/problem.
That's why you need to have backlog grooming sessions regularly. Go through the backlog, prioritise it and see what ideas aren't useful anymore (already implemented, obsolete, stupid etc).
I mean yes, you can use the Backlog for that, as a sort of idiot pacifier but that's basically the worst way to deal with that. Preferably you would find ways to educate those people on why their Ideas are bad or low priority so they can learn to give you better input.