How to Manage User Requests If You Go For Agile Project Management with Scrum

19.12.2017
11 min.
title

The Project in Brief

This was a custom app development project that included building extra modules for a content, community, and analytics platform. This platform stood out in many ways:

  • It was helping to drive social conversations through high-quality content created by over 21,000 demographically diverse content creators.
  • It had over 160 million active users across platforms, which included the company’s website, blogs, and social media.
  • It spanned 18,000 social media profiles, 3,000+ blogs, and hundreds of participating brands and digital agencies.

The project featured Agile project management with Scrum as its methodology, where Jira was the project tracking tool. Every Jira ticket contained a detailed description of each requirement.

What We Started With

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

Numerous modules and features

Used daily by over 20 users across editorial, community partnerships, and legal departments

Existing integrations with third‑party systems

Lifefyre for managing user‑generated content

Gigya for customer identity management

KitchenSink for managing submitted articles

Piwik for analytics

PubOps and NetSuite for financial management

New integrations required

PactSafe contract management system

Google Analytics

PredictionIO for predictive analytics

New features required

Extended member search capabilities

Advertising and content generation

Campaign payment tracking

Auto-emails to users on specific events

Campaign feed with performance data for clients

Required changes to business processes due to the customer’s new business strategies to be reflected in the system

Clients’ approvals of campaign participants

Clients’ approvals of sponsored blog posts

New members’ onboarding

Payment automation

Surveying of potential campaign members

Bugs

Users submitted at least 2–3 bugs per week

All these factors combined, the development team was regularly getting an avalanche of requests of different complexity and urgency. Here’s a table to illustrate this process:

Bugs Single-feature requests New-modules requests

Reported for different parts of the system

On average, 4–5 requests per week, reported for different parts of the system

Requests to change or add entire modules and processes to the system

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

Some requests were already structured and scheduled for development, and we had a roadmap for creating a few new modules, like in the table below:

Planned improvements New modules
Improvements to the blog posts lifecycle

 A campaign dashboard for clients

Improvements to the survey workflow

Clients’ approval of campaign participants

Changes to email notification management

Clients’ approval of content

Campaign settings cleanup

Unified member search

Rebranding  

At the same time, the team had to thoroughly prioritize all the other ongoing improvements required and bugs reported, and incorporate them gradually into each sprint as they were the only ones responsible for all the tasks.

Searching for a Project Management Tool

The total number of requests coming from users was so large that it made no sense to create a Jira ticket for each of them as soon as they arrived. In that case, our backlog would become too huge and hard to manage.

The team couldn’t allow any user to create tickets with their requests in the backlog either, while getting requests by email was not an option as there were high risks of losing or overlooking them.

All in all, the team started looking for a separate place to register and track all the discussions and supported materials regarding each request, as their Agile project management with Scrum prescribed.

That place was to be Trello for managing user requests before they are ready to go to Jira as new tickets. In Trello, the team 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 Features

Corresponding stakeholders were added to each board via email invitations containing the link to join Trello. Then, several lists of cards were created in each board. Some of them were labeled as critical for the team’s success with request management: Big Initiatives, Roadmap, Product Requirements, and Go-To-Market.

Lists on the Trello board

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

Big Initiatives

Product owners managed this list by adding new big changes 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 comments.

However, there were no detailed requirements and no plans defined for the development of these features—these would be going into other lists.

Roadmap

The cards from the Big Initiatives were moved to this list to show what was planned for development. The cards could be updated with milestones, action items, and other relevant details. They then could be 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. The team used labels to visualize the status of each feature in the list, for example, “In progress” or “Requirements gathering.” This way, the roadmap remained informative and always up-to-date for everyone on the project.

Product Requirements

On this list, cards marked high and mid-level requirements to the features from the Roadmap. At this point, stakeholders were involved to work with the Trello cards too.

Questions could be submitted as comments in the corresponding cards, with username mentions triggering email notifications. Stakeholders could also subscribe to cards, lists, and boards to stay notified about all the changes even if their usernames were not explicitly 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 the team could break down the requirements into user stories and create tickets in Jira for them.

The Jira tickets contained the details of the corresponding requirements and enabled chats with stakeholders for updates and questions. At this stage, Trello could also be used, for example, to get input from a user who had no access to Jira. Once requirements in tickets were ready and approved by the stakeholders, the tickets were gradually added to sprints prioritized accordingly by the product owner.

Go-To-Market

The cards were moved to this list from the Product Requirements. At this stage, the feature or a module in question went live, which meant all the related Jira tickets were released.

Since these were completely new modules or significant changes to existing processes, all the tickets had to be released at once. Within a few days after the launch, the stakeholders were able to evaluate how it works in the live environment, and the team used the cards in this particular list to register their feedback.

Ongoing Change Requests

To manage ongoing change requests, the team used several lists: Feature Requests, Bugs, Priority Queue, Jira, Demo, and UAT Done.

Feature Requests

The team used this list to manage requests for small changes or new features in the system, and this is where the stakeholders were encouraged to create cards by themselves once they needed any.

The team trained the stakeholders to describe their issue requirements as clear as they could, making sure to mention the product owner and the business analyst, to attach screenshots, to add links and any supporting materials, and quickly react to the team’s questions posed in the cards.

When any of the features from these cards got its Jira ticket, the Trello card was updated with the Jira ticket ID to link the two project management tools together. This was especially useful when several people were working with the same requirements.

Here is an example: a user needed to add attachments to emails she created in the system and then send them to the campaign members. This feature existed for other types of campaigns but wasn’t available for the expert type she had been working with at the time.

Below is the screenshot of the card she created with a title, a description, and an attachment showing the screenshot from another campaign type with the same feature. The team asked a few additional questions about the feature, tagging the user in the card. She received the notifications and responded very quickly. All the communication was 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

Bugs

This list was handled in a similar way to the Feature Requests. The only difference was in the type of issues submitted here—this list contained only bugs found in the system. The team trained the users to describe their discovered bugs comprehensively, to include screenshots and links to the affected pages, to describe the environment, and so on, so that the team could easily reproduce the bugs. Here is an example of a bug submitted by a 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 Feature Requests and Bugs.

Either the team or the product owner created Jira tickets for the issues on the Priority Queue list, set a high priority for them, and moved them to the top of the backlog. If the issue was critical (mostly related to bugs), the team added the ticket to the current sprint immediately and assigned a developer to start working on it.

Here, it’s worth noting that there was only one team to do all the development work for the system, and sprint backlogs always included all types of issues—new features, change requests, and bugs. So the situation where the team had to add urgent tickets to the current sprint was not something unusual.

Jira

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

Demo

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

UAT Done

After the demo, users were performing UAT testing on the demoed features, and the corresponding cards were moved to the UAT Done column in Trello once successfully tested.

After that, the team archived the cards (usually in 2 weeks after the launch) to keep the UAT Done list short and up-to-date. The team did not archive at once in order to give some time just to be sure that everything worked 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 a Trello card, namely, a feature request or a bug submitted by a user (all transitions between Trello lists were manual):

Trello card lifecycle: transition between the lists

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 regular 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 in Agile project management with Scrum.

Here are 5 main steps of the communication flow established:

1.  Ensuring All Involved People Understand the Process and Their Role in It

Every stakeholder should be instructed on how to use Trello and Jira. Also, they should understand in detail actions to take during the lifecycle of their requests. 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.

The project team encouraged the stakeholders to use Trello for resolving any issues related to the system development. There was even a How to use the board card in Trello with instructions for users. 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

2.  Scheduling Regular Meetings with Stakeholders

The team had weekly online meetings with each group of the stakeholders. These meetings helped keep everybody in the loop regarding the project. The agenda of these meetings always included the following aspects:

  • What is shipped? The demo and collection of user feedback
  • What is coming up? Updates on the status of existing issues and plans, changing priorities if necessary
  • Questions to users about their previously reported issues
  • Any new issues and users’ needs

The meetings were always linked to Trello and sometimes Jira boards, so that users could see and track their issue statuses and their lifecycle in general. During the meeting, the team ran through the Trello cards, added comments to them, moved them to other lists, reprioritized, showed users any issue status updates, etc.

This all helped the team make the whole process of managing requests transparent to the users. It also proved that this process worked as users always knew the status of their issues, reasons for them not being resolved yet, priorities, and directions of the system development.

3.  Pre-Planning Meetings with Product Owners

The team held regular meetings several days before planning for the next sprint. At such meetings, the business analyst on the project and the product owner reviewed the backlog and reprioritized issues to ensure those prioritized the highest would go to the next sprint.

4.  Conducting Demos

This step includes demonstrating big chunks of the new functionality and gathering user feedback in Trello, usually in the form of checklists in the corresponding card. The team did it during the demo, so all the stakeholders saw what was being written. Once the stakeholders were invited to the card, they received notifications with the link to the card with the demo feedback.

Example of demo feedback

Example of demo feedback

5.  Using Different Trello Boards for Different Areas of Your Systems and Projects

In that particular project, the team had separate boards for different groups of stakeholders, along with another board to manage design issues with the project designers. The team used Trello boards to manage requirements before creating epics and user stories in the Jira project backlog.

The Bottom Line

Together with well-organized communication with the stakeholders, the overall process organization benefited the project in several ways:

A shorter backlog

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

Jira stored only the issues with clear requirements and those prioritized for implementation in the measurable future. Until that, they resided in Trello.

No missed requests from the stakeholders

The cases when a stakeholder’s request could be lost were completely eliminated.

The same way, no questions to the stakeholders were lost. The stakeholders didn’t need to search their emails anymore but just go to Trello, open the card they had created by themselves, and view and update all the details in it.

Regular meetings for reviewing the Trello boards with all the stakeholders made sure everyone was on the same page.

Reduced request handling time

The request handling time was reduced thanks to a clear and transparent workflow, fully understood by all the participants.