Understanding Feature Requests
- Business
Feature ideas may come from various sources, and in the context of a Scrum team, they are a great source for product owners to determine what user stories to put in their product backlog. Some ideas seem natural and logical, while others may seem so out of place that the sanity of the person that came up with it is put into question.
But ignoring silly feature requests is usually a mistake. After all, there's someone out there that thinks it's a good idea, and it's very likely that there are other people out there thinking the same way.
Similarly, blindly adding a nonsensical feature request to the product backlog because someone within the organization pushes for it is also a pretty big mistake. I mean, it may indeed be the most important thing for the organization and the guy just knows something that the product owner is not aware of, or it may be the other way around and the feature implementation would do some serious sabotage.
So how should product owners deal with these feature requests then?
My experience
Here are the common reasons I've witnessed for bizarre feature requests:
- The product is not well understood.
- The product is attempted to be used for something other than its intended purposes.
- The product has an existing substitute feature, but it has a bad user experience when used in the desired way.
- The product contains a bug, and the request is a workaround.
- The product does not match an existing or desired external workflow.
Note that in all cases, it is the result of a mismatch between product expectation and product implementation. But why would someone have seemingly-unreasonable product expectations in the first place?
The thing is, a feature request usually only contains a suggested solution to someone's problem. The problem they are actually trying to solve is often omitted.
In fact, the problem may seem so obvious to the person making the request that they will never think of mentioning it naturally. Worse, sometimes the person may incorrectly think their request would solve their problem, fail to realize that such request would cause even bigger problems, or even have a bad understanding of the problem they're trying to resolve.
Investigating the root cause
A really easy technique to understand a feature request is to drill for a meaningful motive. To do so, a product owner simply asks the person that made the request how the feature would help them. If the answer is not satisfactory, he continuously asks for more details until satisfied. At the end, he should confirm that he understands the information correctly, and if he believes another solution is already available, he should verify to confirm or deny it.
Sometimes however, the conversation will go nowhere because the product owner is missing the context or having bad assumptions. In this case, he can ask for the workflow and how the product fits or should fit into it. This additional information should be able to clarify any misconceptions and terminology differences, and help determine which part of their workflow is problematic. If still applicable, drilling for a meaningful motive should become a lot easier at this point.
Intermediates should be avoided, as they are usually an impediment. They are likely to possess partial or incorrect knowledge of the problem and context, introduce their own bias and cause unnecessary delays for answers. And yes, I realize that this sounds a bit weird considering a product owner also acts as some sort of intermediate to the development team, but the key difference here is the product owner should have all of the necessary knowledge due to their work invested in gathering it and understanding it. This cannot be guaranteed from general intermediates, and the Scrum master should be involved if attempting to bypass them becomes a problem.
Also keep in mind that while investigation is important, efficiency is just as important. In particular, a good product owner should be able to realize when an investigation is worth pursuing or if it's going nowhere due to lack of cooperation.
Managing the knowledge
By doing this investigation correctly, a product owner should have a good idea of what the problem is. It should be documented along with the original request. The latter may not be fulfilled, but the product owner may still want to prevent the problem from happening in a better way, such as tackling the root cause of the problem, solving a more general case, or simply ensuring that other users won't be too negatively impacted.
In the case of internal requests, I recommend for product owners to keep an open communication and explain to the related stakeholders why they may not be priorities as-is and if something is about their problems in the future. However, if these internal requests are becoming too insistent, this impediment should be brought up to the Scrum master.
In any case, if a product owner adds anything to their product backlog and can't explain to their development team why it's the best thing ever for their organization's growth besides the even higher priority stuff, then he's doing a disservice to everyone. Not only is it time not spent developing something more productive, but the team is more likely to deliver something of bad quality that will not meet user expectations.
Remember: it's the product owner's responsibility to be the keeper of the product backlog, not anyone else.
This post is the first part of an ongoing series about optimizing Scrum product backlogs in Agile teams. I invite you to subscribe to my blog if you want to read follow-up articles on this topic or on other software-related subjects. Until next time!
Related content I wrote
I Designed the Perfect Gambling Game, But...
- Mathematics, Business, Game Design
Back in 2006-07-08, during the 13th Canadian Undergraduate Mathematics Conference at McGill University, I presented a gambling game I designed with the novel property of being both advantageous to players and the house, and that despite this proprety, that pretty much nobody in their right mind…
Current Generative AIs Have Critical Quality Issues
- Business, Quality Assurance, Security
The hype for generative AI is real. It is now possible for anybody to dynamically generate various types of media that are good enough to be mistaken as real, at least at first glance, either for free or at a low cost. In addition, the seemingly-creative solutions they come up with, and the…
Current Data Serialization Formats May Be a Waste of Money
- Programming, Business
Storing data. Transmitting data. Processing data. These fundamental topics of computer science are often overlooked nowadays thanks to the historical exponential growth of processing power, storage availability and bandwidth capabilities, along with a myriad of existing solutions to tackle them. So…
Upgrading Your Cybersecurity from Cowboys to Sheriffs
- Security, Business, Anecdotes
Roaming throughout the countryside, dangerous desperados are awaiting in their hideout for the perfect opportunity to rob their victims in silence. Powerless, the authorities have posted wanted posters on public boards with cash bounties for any information that could lead to their arrest or death…
Scrum Is Not Agile
- Programming, Business, Psychology
While there is no denying that Scrum revolutionized the software industry for the better, it may seem a little strange to read about someone that dislikes it despite strongly agreeing with the Agile Manifesto, considering the creator of Scrum was one of its signers. However, after having experienced…