Birthday present with too much functions

I'm not that good in buying birthday presents, especially for my mother. Every year I ask what she would like to get for her birthday and this year I expected she would say that it is a present to have me at her birthday and a present wasn't necessary, until this year. She really would like to get a small handheld vacuum cleaner.

This week I went to a shop to buy me such an item. In the store I noticed I didn't have any knowledge of handheld vacuum cleaners so I asked for advice. As a professional tester I noticed the differences between all those different items. I asked questions about the functions and what use they are for. I got explanation about the meaning of difference in power and performance. A demo of usability thought me more about those things.

And here I made the mistake; I bought the best handheld vacuum cleaner which was available in the store for an acceptable price. It had everything on it, easy to use and maintain. Powerful to cleanup even the tiniest dust and it also looked beautiful.
The only disadvantage it had and also the other machines: it was not small.

I'm sure that we do this all the time also in development and testing. We start with the basic needs and requirements and during the project we find out more requirements and also testing them as we need them. We judge them and tell the business if those are working well it can be shipped to production environments. Business will get overwhelmed by those extra nice and really usable functions. Only the main functionality it forgotten: it should be small as the main purpose was for intended usage since the organization has for those heavy jobs a real vacuum cleaner. Perhaps you can compare it with asking for an excel sheet to use as a small database and giving them a web based SQL driven database with fancy windows.

In traditional projects and development methods this is mostly avoided as requirements are fixed and design is available. The system is tested against those requirements. In Agile projects this is in my opinion a risk. The requirements are not always fixed and grow during the project as business involvement is huge. Those change in requirements is not only triggered by their change of thoughts, it is also triggered by the team as they want to give something good and beautiful. They want all the best for the business. I can imagine that functions which initially were nice-to-have becoming must-haves.

This could be avoided by keep asking the right questions: What do you need? Why do you need it? How are you intending to use it? What if you get less and what if you get more? Do you still want it even it has more? Is it acceptable? ....?

Often we think less is bad, I think more is even worse. As a system contains more functionality then needed it will have also impact on the business processes. Procedures has to be adapted, people needs training to use that additional functionality and so on.

Fortunately for me, my mother liked the handheld vacuum cleaner. And she loved it on its initial usage. The initial requirement was basically met and agreed with me that those machines are not that small as in the past as they became better. I know although in the future she will come up with disadvantages she will never telling me that the machine was too big after all. She perhaps will use it lesser then intended.

In this case a sharply priced machine with too many functions which didn't meet the main requirement completely will become a too expensive investment. This makes me think about the situation in our field: Are we responsible to give advice when requirements are not met initially although the user is more than happy? Are we responsible to give information about this during the process? What tools and procedures do we have to maintain this responsibility?