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:
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.
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
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
Surveying of potential campaign members
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
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.
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:
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.
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.
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.
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.
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.
To manage ongoing change requests, the team used several lists: Feature Requests, Bugs, Priority Queue, Jira, Demo, and UAT Done.
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:
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:
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.
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.
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):
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:
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.
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:
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.
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.
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.
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.
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.