Answer to: How should small but highly requested features be prioritized in technically driven B2B products?

None of these methods is limited to "technical value". In fact, very often "business value" is considered, be it business value for the users (e.g. enabling higher productivity) or for the software producer (e.g. less calls to the helpdesk, less loss of customers going for better products). So Moscow, Rice etc should work if the business value related to user's emotion is taken into account. In this sense, a feature expected by many users and for a long time should go a least to ShouldHave (Moscow) and would have a high reach (Rice). But I understand that it's not that easy: It's not obvious to quantify the business value associated to users dissatisfaction, that has moreover a cumulative effect; It is not easy to objectively assess if it's still really dissatisfaction or if the users got used to work without and have found efficient workarounds (if it was awaited for a long time). More generally, even if we address well the prioritization (e.g. feature upgraded to ShouldHave or even MustVave), we may still face the traditional scheduling issue of starvation when there are many feature requests: there may always be a features of comparable priority that are deemed more important and use all the resources available in the current cycle. If you are confronted with this, you may fine tune your prioritization process to consider within the same priority class a booster for a limited number of very small cost items: the pro: it's sometimes quicker to implement such a feature than to discuss again and again why it should or not be included in the current sprint; the cons: the risk is that too many low cost changes might be boosted and end up consuming resources, delaying significantly bigger items (not to speak of the sometimes underestimated interdependencies that make the small change a little more tedious than initially expected, see also Hofstader's law). This is why it is important to limit the number of boosted small changes (a few per sprint would not significantly impact the overall outcome).