How We Managed Huge Number of User Requests on One Project

15 min.

When a software development project involves a lot of stakeholders and end-users, the dev team will have to deal with numerous requests for new features or changes in different parts of the system being developed, coming via emails, phone calls, or raised at meetings. This may become a constant headache for a responsible person because of the following reasons:

  • Requests have to be registered somewhere
  • Requests have to be prioritized and planned for development
  • Requests from different stakeholders may contradict each other
  • Requests have to be analyzed and decomposed, detailed requirements have to be elicited and documented
  • Request status has to be tracked and easily available for requestors
  • People’s expectations regarding requested features going live have to be managed.

In this article, I will share how we handled these issues on one of our projects.

The project was about further development of an existing content, community and analytics platform that:

  • Helped driving social conversations with quality content produced by over 21K demographically diverse content creators
  • Targeted across platforms – the company’s website, blogs and social media
  • Reached 160M+ online users
  • Was growing across 18K social media profiles, 3K+ blogs and hundreds of participating brands and digital agencies.

SCRUM methodology was used to manage the project, Jira was the project-tracking tool, and every ticket in Jira contained a detailed requirements description.

A few words about the state of the system we started to work on:

Lots of modules and features

Used in daily work by over 20 users

Editorial, community partnerships, and legal departments

Existing integrations with 3rd party systems

LifeFyre for managing user-generated content

Gigya for customer identity management

KitchenSink for user articles management

Piwik for analytics

PubOps system & Netsuite for finance management


New required integrations

PactSafe contract management system

Google Analytics

PredictionIO for predictive analytics

Users need lots of new features

Extended member search capabilities

Advertising and content generation

Campaigns payment tracking

Auto-emails to users on specific events

Campaign wall creation with performance data for clients

Essential business processes are not fully covered; Processes were changing as a result of new business strategies developed by the customer

Campaign participants approval by clients

Sponsored blog posts approval by clients

New members onboarding process

Payments automation

Potential campaign members surveying



At least 2-3 bugs per week were submitted by users

All these factors resulted in a large number of requests of different complexity and urgency regularly coming from users in different departments. 

Bugs Single feature requests New modules requests

Reported for different parts of the system

Reported for different parts of the large system

4-5 requests a week in average

Requests to change or add whole modules and processes in the system

By the time we joined the project, there were around 20 such requests

Some things were already structured and planned for development, and we had a roadmap for creating a few new modules – see examples in the table below:

Planned improvements New modules
Improvements to blog posts lifecycle

Campaign dashboard for clients

Improvements to survey workflow

Campaign participants approval by clients

Changes to email notifications management

Content approval by clients

Campaigns settings cleanup

Unified member search


At the same time, we had to thoroughly prioritize all other ongoing improvements required and bugs reported, and incorporate them gradually into each sprint, as we only had one team for doing everything.

The total number of all the requests coming from users was so large that it made it inconvenient to create a ticket in Jira immediately after the request arrived – our backlog would become huge and hard to manage. We could not allow any user to create tickets with their requests in our backlog, and if they would send all their requests to us via emails (this is what they did earlier), there were high risks to lose or forget about some of them. We needed a separate place to register and track all discussions and supported materials regarding each request.

The decision we came up with was using Trello to manage user requests before they “deserve” to go to Jira as a new ticket. In Trello, we created several boards to manage requests from the main groups of users working in different departments:

Trello boards
Users can view their personal Trello boards

Requests for New System Modules and Big Features

For each board the corresponding stakeholders were added via sending email invitations with the link to join Trello. Then, several lists of cards were created in each board. The most important of them, which really helped in user requests handling, were the following:

Lists on the Trello board
Lists on the Trello board: manage new big system modules and feature

Big Initiatives

Product owners managed this list adding the new big changes that were required. The cards in this list could contain such elements as high-level feature descriptions, goals, known blockers and constraints, phases, open questions, KPIs, to-do lists, and any comments. However, there were no detailed requirements and no plans defined for the development of these features yet. 


The cards from Big Initiatives were moved to this list to show what is planned for development and when. The cards could be updated with milestones, action items and other relevant things, and drag-and-dropped to the list to appear in the appropriate order — for example, to reflect the roadmap timeline. New cards could be added to the roadmap as well. We also used labels to visualize the status of each feature in the list, e.g. “In progress”, or “Requirements gathering”, etc. – this way, our roadmap remained informative and always up-to-date for all of us, including stakeholders.

Product Requirements

Here we created cards to note high and mid-level requirements to features from the roadmap.  At this point, we started involving stakeholders to work with cards in Trello. In addition to personal and web meetings we had, quick questions to a user or request for some additional info was submitted as  a comment in the corresponding card, with the user mentioned by @username, so that they receive an email notification with the comment and the link to the corresponding card in Trello. We also subscribed some stakeholders to cards, lists, and boards so that they were always notified about changes even if not mentioned. 

The purpose at this stage was to understand the scope of the feature, its main components, and the steps needed to implement it, so that we could break down feature requirements into user stories and create tickets in Jira for them. When we had tickets in Jira, the details of the corresponding requirements were described in Jira, and any required written communication with stakeholders was conducted in the tickets as well. Trello could still be used, e.g. in cases when we needed some input from a user who had no access to Jira. Once requirements in tickets were ready and approved by stakeholders, the tickets were gradually added to sprints, being accordingly prioritized by the product owner.

Go to market

The cards were moved to this list from “Product Requirements” when the whole feature/module went live that meant all the related tickets in Jira were released. Since these were completely new modules, or significant changes to existing processes and thus user interface, all the tickets had to be released at once. Within a few days after the launch, our stakeholders were able to evaluate how it works in the live environment, and we used the cards in the Go to market list to register their feedback.

Ongoing Change Requests

To manage ongoing change requests we used the following lists:

Feature requests

We used this list to manage requests for small changes or new features in the system. What was really important for the process was that we instructed our stakeholders to create cards by themselves once they had any needs for changes in the system. And we trained them to describe the issue they had and their requirements as clear as they could, mention the product owner and business analyst in cards, attach screenshots, add links and any supportive material that could help, and quickly react to our questions posted in the cards. When a ticket was created in Jira for a feature from this list, I added the ticket ID to the card title in Trello to identify that the ticket had already been created in Jira for this (this is especially useful when several people work with requirements).

Here is an example of a small issue raised by a user: she needed an ability to add attachments to emails she created in the system and then send them to members of the campaign. This feature existed for other types of campaigns but wasn’t available for the “expert” campaign type she had been dealing with at the time. Below is a screenshot of the card she created: title, description, and attachment to show the screenshot from another campaign type with the same feature. We asked a few additional questions about the feature tagging the user in the card; she received notifications and responded very quickly. All our communication is documented in the Activity section of the card:

The Activity section in Trello cards
The Activity section in Trello cards keeps all communication regarding the card in one place


This list was handled in a similar way to the “Feature requests” one, the only difference was in the type of issues submitted here – this list contained only bugs found in the system. We trained our users to comprehensively describe them (include screenshots and links to affected pages, describe the environment and so on), so that we could easily reproduce them. Here is an example of a bug submitted by our user:

Example of a bug submitted by a user
Example of a bug submitted by a user

Priority queue

Any issues requiring immediate attention were created in this list (or moved from “Featured requests” and “Bugs”). Me or the product owner created tickets in Jira for the issues on the “Priority queue” list, set high priority for them and moved them to the top of the backlog. If the issue was really critical (it was mostly related to bugs), we added the ticket to the current sprint immediately and assigned a developer to start working on it. Here I’d like to note that since we had only one team to do all development work for the system, sprint backlogs always included all types of issues – new features, change requests and bugs – so the situation where we had to add urgent tickets to the current sprint was not something out of the ordinary.


Once the ticket was created in Jira for a Trello card issue and added to the next sprint, the Trello card was moved to the Jira column, and a Jira ID was added to the card title. This way all the stakeholders could see that the issue was in development already.


An essential part of our project was conducting regular demos of implemented features to stakeholders. The cards with the issues to be demonstrated were moved to the “Demo” list.

UAT Done

After the demo, users performed UAT testing on the demoed features, and the corresponding cards were moved to the “UAT Done” column in Trello once successfully tested. After that, we archived cards (usually 2 weeks after the launch) to keep the “UAT Done” list short and up-to-date. We did not archive at once in order to give some time just to be sure that everything works smoothly in production.

Lists on the Trello board: manage ongoing feature requests and bugs
Lists on the Trello board: manage ongoing feature requests and bugs

A simple diagram below depicts the lifecycle of the card, i.e. feature request or bug submitted by a user, in Trello (all transitions between Trello lists are manual):

Trello card lifecycle
Trello card lifecycle: transition between the lists

Tips to Ensure the Process will Work

A great number of stakeholders, plenty of change requests, continuous system development with constant additions of new modules and features in line with the company’s market strategy – all these factors made communication one of the key factors to run the project successfully. Here are the main components of the communication flow we established:

Ensure all involved people understand the process and their role in it

Every stakeholder should be instructed on how to use Trello and Jira. Also, the process to follow in the lifecycle of their requests should be thoroughly explained to them. They should know what to do when they have a request for change or a critical bug, or have a question, or want to know their request status, etc.; we encouraged our stakeholders to actively use Trello on any issues or questions related to our system development. We even created the “How to use the board” card in Trello with instructions to users. And it’s important to provide Trello and Jira training rather than have users send emails regarding any issues related to system development. This way, it will always be easy to find all the information about any issue.

“How to use the board” Trello training card
“How to use the board” Trello training card

Schedule regular meetings with stakeholders

We had weekly online meetings with each group of stakeholders. These meetings helped to keep everybody up to date regarding the project. The agenda for these meetings always included the following aspects:

  • What is shipped? Demo and collect user feedback.
  • What is coming up? Update on existing issues status and plans, reprioritize if necessary.
  • Questions to users about their previously reported issues.
  • Any new issues and needs of users.

The meetings were always based on Trello and (sometimes) Jira boards, so that users can see and track their issues status and their lifecycle in general. During the meeting, we opened Trello cards, added comments to them, moved them to other lists, reprioritized, showed users issue status updates, etc. This all helped to make the whole process of managing user requests transparent to users. It also proved that this process works as users always knew the status of their issues, reasons for them not being resolved yet, priorities, directions for system development, etc. 

“Pre-planning” meetings with product owners

We held regularly scheduled meetings, several days before planning for the next sprint. In such a meeting, me as a business analyst and the product owner reviewed the backlog and reprioritized issues to ensure the top prioritized ones would go to the next sprint.

Conduct demos

Conduct demos of big chunks of new functionality and gather user feedback in Trello usually in the form of checklists to the corresponding card. We did it during the demo, so all the stakeholders saw what we’re writing, and once the stakeholders were submitted to the card, they received notifications with the link to the card with demo feedback.

Example of demo feedback
Example of demo feedback

In addition to the communication aspect, here is one more point to keep in mind when setting up an efficient process:

Use different boards in Trello for different areas of your system and your project

For example, we had separate boards for requests of different groups of stakeholders, and we found it convenient to have a separate board to manage design issues with our designers.

In our experience, we used Trello boards to manage requirements before creating epics and user stories in the project backlog in Jira. Together with well-organized communication with stakeholders, the overall process positively affected our project in several ways: 

Shorter backlog

With time, our backlog in Jira decreased by about 15-20% of issues, which made it easier to manage.

Only issues with clear requirements and prioritized for implementation in the measurable future were created in Jira; until that they resided in Trello.

Never lose stakeholder requests

We completely eliminated cases when a request from a stakeholder could be lost.

In the same manner, questions to stakeholders weren’t lost, and they didn’t have to find emails to respond anymore, as they could just go to Trello, open the card they had created by themselves, and view and update all the info in it.

Regular meetings with Trello boards review with all stakeholders provided we didn’t miss anything important.

Reduced time of working out requests

In general, the time of working out requests was reduced due to the stated order of working with them, fully understood by all key players.