[idopmstuff]

"Please fill out the feature request form - that will create a ticket." Mark ticket P4.

In all seriousness, the best thing is to have management that clearly communicates what the high level company goals are on a quarterly (or whatever cadence is appropriate for your business) basis. People don't like to hear no, but they understand "the main objective for the quarter is to close $X in new deals in Y market segment, and since this isn't going to directly contribute to that, it's not going to be a priority in the near future."

[ungreased0675]

In my PM work I haven’t had an issue with being transparent with feature requests. I’ll straight up tell people “just because it’s in the backlog doesn’t mean we’ll ever do it.” Most of the time people just want to be heard. People understand you can’t build every feature that crosses the desk.

[deathanatos]

File as P4. Don't hire sufficient engineering to ever get past P0, let alone to P4. Autumn turns to winter, winter turns to spring. A PM comes along "management doesn't like the length of the backlog, it makes them feel bad, so we're going to just delete all existing tickets." The cycle begins anew.

[Cthulhu_]

This is what we do at my current job, they follow "safe" (scaled agile framework - don't look it up if the scrum inforgraphic already gives you shivers), but it boils down to two weeks of tidying, innovation and learning (in practice it's just more regular work) and two days of intensive planning, where from top the main priorities for the quarter are outlined and all the teams figure out what they are going to do and more importantly what dependencies they have on each other so every team can plan that.

[psunavy03]

The most abused concept in SAFe, because people fail to use it as intended (get a snapshot of the next quarter and be ready to pivot if things change) and use it to "lock down the plan," have teams refuse any new requests, and have management judge your "predictability score."

It's a great idea in theory until you see how much two full days of timeboxed planning every quarter beats down dev morale in practice. It's great for teams that literally don't know what they're doing and don't know their dependencies, because it forces them to confront their mediocrity. But you have to move beyond it eventually.