December 19, 2017
The change request process in Agile with Trello
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:
Scrum was the chosen project methodology, with Jira as the project tracking tool. Every Jira ticket contained a detailed description of each requirement.
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:
At the same time, users were regularly submitting 2-3 bugs a week.
The platform was to be integrated with three more services:
The new features required included:
To accommodate the customer’s new business strategies, we were also tasked with changing the following business processes:
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.
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:
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 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 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.
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.
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 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:
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:
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 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.
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 could potentially contribute to IT outsourcing risks. However, we made it work by prioritizing communication through the following steps.
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 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 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.
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.
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.
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.
Together with well-organized communication with the stakeholders, our established change request process in Agile benefited the project in several ways:
To reap the benefits of Agile, project managers need to go through massive cultural shifts and adopt a different mentality. Find out how.
Itransition looks at the common risks in software development projects and ways to timely mitigate them.
ITO remains one of the most effective collaboration models despite the risks. Here’s our take on how to make your outsourcing project truly painless.