How do you deal with non-critical customer feature requests?

[Mike Torrettinni 198]

I had a debate with another self-employed Delphi developer on how to prioritize feature requests. Of course the major factors are: customer (revenue from them), critical issue/bug, how many developers it might affect... so it is very easy to select important, high priority tickets, requests. But the interesting was part about non-critical, suggestions, wishes... do you still put a few of them on list for every release, or you keep putting them at the end of the priority list and they never get implemented.

 

The debate started when he sent me that one of his feature requests for the 'Tool' was to display tool version - the tool doesn't have it displayed on the screen, but you can see it in the file version. So, non-critical, not high priority ticket. He requested it in July 2016,and he just got an email it was implemented in  Dec, 2019.  3+ years for Tool version?

(In the case of this Tool, if you look at the circumstances it's kind of understandable and expected - it's Delphi solution that got acquired, so I guess original developer was squeezed out)

 

I always try to implement even a few such low priority tickets, of course not all - and I only have some very customized feature requests that are years old. My opinion is that you need to put effort also on low priority requests.

The lowest on the list are the very customized features that would take a lot of effort to implement, for 1 customer.

 

if anyone wants to add heir view or experience, please do.

[Anders Melander 1782]

Even trivial changes consume project resources and resources are finite.

Implementing a low priority change takes resources away from higher priority changes and unless there's something wrong with way changes are prioritized I can't really see how one can justify that.

 

The really hard part is weighing all the different factors when calculating the priority. Giving a ticket priority just because it's old doesn't make much sense. But if the age will cause enough customer dissatisfaction that it ends up having economical consequences then it might make sense. Apart from that I don't think age should be a factor. Each time we go through our ticket list we look at it fresh: At this point in time, what is the most important change for us to focus on.

 

In my projects it's common for trivial but very low priority changes to be rejected. I think it's better to let the requester know that there's minimal chance their request will ever be granted, given that there will always be more important changes to work on, than to give them false hope.

[Mike Torrettinni 198]

2 hours ago, Anders Melander said:

In my projects it's common for trivial but very low priority changes to be rejected.

Now thinking about it, I can admin I treat low priority changes also based on relationship with the customer. More personal relationship can swing the vote.

While bigger teams could be flooded with requests (bigger team usually means more customers, more requests), so less personal relationship to affect the vote.

[Anders Melander 1782]

11 minutes ago, Mike Torrettinni said:

I can admin I treat low priority changes also based on relationship with the customer.

Sure. Professional relationships, personal preferences and even mood, are just some of the many factors that affect priority. We're humans.

As long as you know why you are making a choice I don't see anything wrong with making it based on "feelings" or intuition. Just don't make all your choices that way 🙂

I regularly make technical decisions based on intuition. I may not be able to rationally explain why I choose one solution over another, except that one "feels" right or the other doesn't "feel" right.

[dummzeuch 1505]

It's also a question whether the customer is willing to pay for his request to be implemented. My low priority request might have a much higher priority for the customer.

[Anders Melander 1782]

2 hours ago, dummzeuch said:

It's also a question whether the customer is willing to pay for his request to be implemented.

Of course. If the customer can cover the development expenses directly, then that will increase the priority. If the change will benefit other customers, make the product easier to sell or benefit the product in some other way that can also increase the priority and lower the price of the change.

There's still the matter of finite resources to take into account though. Even if the customer pays the expenses up front it still means something else is not getting done.

 

I used to think I could solve the finite resources problem by implementing stuff in my spare time. Unfortunately that just created another problem as the QA, documentation and marketing departments was completely unable to keep up with the amount of features I could produce that way.

 

2 hours ago, dummzeuch said:

My low priority request might have a much higher priority for the customer

I don't understand. So in the scenario you describe you're not the customer but the developer?

If so, why do you have a request at all?

[dummzeuch 1505]

Let me rephrase that: "The request, that I think has low priority, might have higher priority for a customer and he might be prepared to pay for it."

[Vincent Parrett 750]

There's no easy answer to this question, and it's one I've battled with for 20+ years. If it's a trivial change (< 10 min to code and test) and I think it's relevant (not all customer feature requests are, we have to evaluate how they apply to all users)  I'll often just go ahead and do it immediately after reading the ticket. It's appreciated by customers, but a double edged sword, the more you do it the more they ask 😉

[Uwe Raabe 2057]

Often the time spent for low priority tickets would better be used for refactoring the code - even if the only benefit is the developers better understanding the code and ease maintaining it. That might not impact your customers directly, but definitely on the long term. First implementing that low priority ticket instead may as well have the opposite effect.

 

 

[Guest]

8 minutes ago, Uwe Raabe said:

Often the time spent for low priority tickets would better be used for refactoring the code

Indeed, most the time one leads to the other, i mean refactoring and implementing features, for that i always go through ToDo list before refactor or implement a new feature.

[Anders Melander 1782]

3 hours ago, Uwe Raabe said:

First implementing that low priority ticket instead may as well have the opposite effect.

Yes. I'm sure we all experienced that a simple, innocent change ends up leading to much more work later one because we introduced a bug or side effects that we didn't think of.

[Mike Torrettinni 198]

10 hours ago, Vincent Parrett said:

It's appreciated by customers, but a double edged sword, the more you do it the more they ask 

In my case (self-employed) this is actually wanted/needed as it means the customer is engaged and more chance it will be a long time customer.

[Lars Fosdal 1791]

Every request needs evaluation to understand WHY the request is being raised, and if the request actually is what the customer needs - or if he is just attempting to scratch an itch instead of curing the cause of the itch.