September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
In one case we tracked all their incoming requests by tickets. In another case and which is manageable for both the parties, we had them add their ideas in a shared document - OneDrive, for instance. Periodically we were reviewing this document and picked the business-priority items for future improvements.
There are two aspects to this:
1. Organizing and communicating the backlog of requests
2. Prioritizing a backlog of requests
The former is more of a mechanics issue - pick a tool based on your needs, import the requests and provide a means for requestors to pull info out of it.
The latter is much more challenging - there are numerous methods for a product manager to prioritize what comes next - buy a feature, prune the product tree, WSJF and many many others. Picking the "right" option for your context will take some time and you may not get it right the first time.
What you describe is one of the main reasons people lose faith in developments ability to deliver. You do not say whether you are using an Agile framework or not but lets assume that you do. The most important, and difficult, part of the prosess is the ability to say no. If every 'legit' requirement is popped onto the backlog we end up where we do not want o be - stakeholder end up waiting for months for their requirement to surface. You could then also end up with a situation where you cannot trim the tail which result in a larger amount of support issues, meaning a lower velocity, menaing the 6 months wait gets longer, meaning .........
It is very important to manage the size of your backlog by doing first pass prioritization where some request will not make it onto the backlog. Something like MoSCoW helps.
Please login or join to reply