Introduction:

We appreciate if customers provide ideas on how we can improve our tools to suite their needs even more.
Many clients ask how we process Feature Requests. Here is an explanation how it is done!

Related blog article: https://bluetelligence.de/en/feature-request/

Two general processes we follow

1. Estimation of available capacity within the Software Engineering team. This is the amount of developers and colleagues who specify the work and the available working days (considering their average holidays/trainings etc.).
   The blocks how the effort is planned is:
   1. ~60% reserved for Features (this includes also 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, etc.)
2. Estimation of the actual Feature Requests (internal, as well as external) - this is aligned to the SAFe - WSJF Process (→https://www.scaledagileframework.com/wsjf/; © Scaled Agile, Inc.)
   1. Estimation of the "Cost of Delay". To give the clients' feature requests a priority we add points for the request itself, depending on amount of users, etc.
      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 those 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 ahead for the next release. Changes to the release are done as a very conscious decision.

At 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 actually cause a problem implementing them.
Depending on how many other important and beneficial Requests are in queue, the Feature Request moves up the ladder for later implementation.

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