I found myself reading an article by Adrian Kosmaczewski where he is claiming that developers should say more “noes” instead of “yeses”.

Perhaps 3 years ago I would agreed with him and say that developers probably should spend more time denying requirements than accepting them. But what I learned all these years managing software engineer teams is that most of the requirements (specially in applications that are already running) are made by the wrong people and “because they have heard” or “based on some customers feedback”. If the features of the application you work are based on both or one of them, then you probably have faced this same situation. Even when the requirements come from the people who use them you have to be careful with them.

I have read some books and lived this experience a little bit to tell you that the problem is WHEN you should say “yes” or “no”. And sometimes the problem is accepting requirements without any previous base information.

When the requirement decisions are interfering with the application development and/or the application is not following the course that it should there are minor techniques that can help:

Product Backlog

This is why when using Scrum you have a Product Backlog. Requirements, like a good wine, need time to get mature and to acquire the correct value.

Personas

I worked with an UX Manager that proposed a great technique to put requirements in the right . He proposed that we create the personas who use our application. Each of these personas had a weight and value to the application and to the company. Each one needed different features. Based on the weight of the persona and the amount of use among all these personas a feature got more value and was ranked with a higher priority. So basically in the end features with higher priority were done first even if they were newer.

In the end…

Working a lot with Scrum and Agile techniques has taught me that there is no right or wrong, there is not a magic formula that will solve your problems. You have to see and try different techniques and you will see which of those work better based on your team and the culture of your company. Sometimes is better say no than yes and other times saying yes and letting the feature die by itself will prevent you from having an unnecessary debate with the product owner or manager or whoever is making the decisions.