The change request process in Agile with Trello

The change request process in Agile with Trello

December 19, 2017

Elena Belkovskaya

Senior Systems Analyst

We invited one of our teams of custom software developers to walk us through their change request process they adopted on one of their Scrum-led projects.

The project consisted in 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.

Scrum was the chosen project methodology, with Jira as the project tracking tool. Every Jira ticket contained a detailed description of each requirement.

What we started with

By the time we joined the project, the platform’s numerous modules and features were used daily by over 20 users across editorial, community partnerships, and legal departments.

There were the following 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

At the same time, users were regularly submitting 2-3 bugs a week.

The changes required

The platform was to be integrated with three more services:

  • PactSafe for contract management
  • Google Analytics for web analytics
  • PredictionIO for predictive analytics

The new features required included:

  • Extended member search capabilities
  • Advertising and content generation
  • Campaign payment tracking
  • Automatic emails to users on specific events
  • Campaign feed with performance data for clients

To accommodate the customer’s new business strategies, we were also tasked with changing the following business processes:

  • Clients’ approvals of campaign participants
  • Clients’ approvals of sponsored blog posts
  • New members’ onboarding
  • Payment automation
  • Surveying of potential campaign members

All these factors combined, the development team was regularly getting an avalanche of requests of different complexity and urgency. Some requests were already structured and scheduled for development; others needed to be planned following our Agile transformation roadmap. 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.

Choosing a change request processing 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, otherwise our backlog would become too huge and hard to manage. 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 supporting materials regarding each request.

That place was to be Trello for managing users’ change 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:

Users can view their personal Trello boards

Requests for new system modules and features

The respective 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, such as Big InitiativesRoadmapProduct Requirements, and Go-to-Market.

Trello lists

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 to other lists.


The cards from Big Initiatives were moved to this list to show what was up for development according to the project implementation plan. 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 contained high- and mid-level requirements for the features from 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.


The cards were moved to this list from 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 it 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 RequestsBugsPriority QueueJiraDemo, and UAT Done.

Feature requests

The team used this list to manage requests for small changes or new features in the system, and this was 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 their 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 on 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 keeps all communication in one place


This list was handled in a similar way as 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

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.


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.


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 demonstration, users were performing user acceptance testing (UAT) 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 two 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.

Trello lists for managing 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):

Lifecycle of a Trello card

Tips to make it work for your team

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 could potentially contribute to IT outsourcing risks. However, we made it work by prioritizing communication through the following steps.

Ensure everyone is in the picture

Every stakeholder should be instructed on how to use Trello and Jira. Also, they should understand which actions to take at each stage of their request processing.

We also added the 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.

Our Trello training card

Meet with stakeholders

Our 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 at the moment?
  • What is coming up?
  • 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 the statuses and lifecycle stage of their issues. During the meeting, the team ran through the Trello cards, added comments to them, moved them to other lists or reprioritized, 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, as well as the priorities and directions of the system development.

Meet with product owners

The team held regular meetings with product owners several days before planning for the next sprint. During such meetings, the business analyst assigned to the project and the product owner reviewed the backlog and reprioritized issues to ensure those at the top of the priorities would go to the next sprint.

Conduct demos

This step included 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. When the stakeholders were invited to the card, they received notifications with the link to the card with the demo feedback.

Example of demo feedback

Combine different Trello boards

On 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, our established change request process in Agile benefited the project in several ways:

  • The Jira backlog decreased by 15-20% of issues, while all issues had clear requirements and were properly prioritized for development.
  • No change request was lost as well as no questions to the stakeholders remained unasked as all of these details could be conveniently found in Trello.
  • Request processing got quicker thanks to a clear and transparent workflow fully understood by all the participants.