We are thankful when you provide us with ideas on how we can improve our tools to best meet their needs.
Many customers ask how we handle feature requests. Here is an explanation of how this is done!

...

1. Estimation of available capacity within the Software Engineering team. This estimation of developers and colleagues who specify the work and the available working days (considering their average holidays/training).
   The blocks of how the effort is planned are:
   1. ~60% reserved for Features (this also includes the Feature Requests of clients)
   2. ~15% reserved for Bug fixing (most bugs are discovered internally, without becoming public on the users' end)
   3. ~20% reserved for "architectural runway" so that we can implement "reworks/redesigns" within the software. This is a cleanup to implement further feature requests.
   4. ~5% reserved for miscellaneous (additional meetings, unforeseen topics)
2. Estimation of the actual Feature Requests (internal, as well as external) - this is aligned to the SAFe - WSJF Process (→https://scaledagileframework.com/wsjf; © Scaled Agile, Inc.)
   1. Estimation of the "Cost of Delay". To give the clients' feature requests priority we add points to the request itself, depending on the number of users
      The general components are:
      1. User-business value: Do our users prefer this over that? What is the revenue impact on our business? Is there a potential penalty or other adverse consequences if we delay?
      2. Time-critical: How does the user/business value decay over time? Is there a deadline? Will they wait for us or move to another solution? Are there Milestones on the critical path impacted by this? 
      3. Risk reduction - opportunity enablement value: What else does this do for our business? Does it reduce the risk of this or a future delivery? Is there value in the information we will receive? Will this feature open up new business opportunities?
   2. Estimation of the Effort/Story Points.

The Feature Requests with the biggest bang!

With the information above we can create a weighted list (Cost of delay divided by the effort).

According to the planned capacity for Feature Requests, we use a 3-tier list (Mandatory, Important, Stretch Target) to prioritize them and work on them during the respective release cycle.
Our release cycle is every 4 months, and we plan for the next release. Changes to the release are done as a very conscious decision.

In the end, this means that we do not decline Feature Requests, only in rare cases where it does not fit into the tool and would cause a problem implementing them.
Depending on how many other essential and beneficial Requests are in the queue, the Feature Request moves up the ladder for later implementation.

Do you have any great ideas? Let us know: https://helpdesk.bluetelligence.de