Implementing Jira in the business development and support teams of a fintech company: the story of Bondora
At the beginning of autumn 2023, we finalized the Jira implementation project in Bondora. Implementing a new tool had two parallel challenges – migrating the financial technology company's 15-year history from Asana to Jira and bringing teams from one platform to another as seamlessly as possible.
In the upcoming article, we will explore the implementation process, address diverse requirements and technical solutions, and delve into the teams' experiences with Jira thus far.
About Bondora
In 2008, at the height of the global financial crisis, Bondora was founded in a student dorm room with one clear purpose: to help people who were failed by banks. Bondora's mission is to enable people to live the life of their dreams without worrying about money.
Why did Bondora choose Jira?
Like Jira, Asana is a project and work management software to plan, track and manage tasks. Although Jira Software was initially created purely as a development solution, it is known for supporting various processes thanks to its versatility:
Some noteworthy advantages of Jira Software over Asana include:
- flexible configuration options for workflows, issue types, fields, views and permissions;
- support for Scrum methodology by functionalities such as sprint, backlog and sprint-based reports;
- extensive integration options;
- dedicated query language Jira Query Language for searching issues;
- Advanced Roadmaps for project portfolio management.
Given Bondora's involvement in software development, the decision in favor of Jira was significantly influenced by the capability to integrate with Azure DevOps, an option not available with Asana.
Aleksandr Knjazetski, head of the development team, pointed out that the decision to migrate was driven by Jira's customizable functionalities, which can be tailored to specific processes and requirements.
Implementation by teams
Initially, Bondora independently initiated the implementation of Jira, commencing with the development teams. The task was manageable as some specialists within these teams had prior experience with Jira Software.
"We encountered challenges with other teams due to their unfamiliarity with Jira functions supporting specific processes. We decided to find experts to help us bring other teams to Jira and share their knowledge of Jira's functions and experience in managing Jira," explained Aleksandr, who managed the implementation project from Bondora's side.
Together we continued the implementation of Jira by HR, marketing, risk, expansion, and finance department's teams. We divided the team transfer into three main stages:
- gathering input - getting to know current work processes, examining Asana projects and boards, documenting requirements;
- configuring a Jira project;
- validation of solutions and, if necessary, making additional changes.
Data migration from Asana to Jira occurred concurrently with the aforementioned stages. Bondora conducted the migration independently; for more details on the nuances and lessons learned, you can refer to Aleksandr's blog post.
We created dedicated Confluence pages for each team to document requirements for fields, issue types, workflows, permissions and notifications.
Template for requirements, in-line commenting and notifying users via @ notation allowed details to be specified directly within the context. We also used Slack channels for quick communication and planning.
Marketing team
Before the marketing department's project migration, it became clear that it was not reasonable to create each Asana project as a separate project in Jira. It was more practical to consolidate the tickets into one project.
"Previously, we maintained two separate Asana projects for Investor Social Media; these were merged into a single Jira project. Additionally, our copywriter utilized a Copywriting board to organize her work," said marketing and sales specialist Suule Vill.
After the migration, it was necessary to carry out some corrections within in the tickets. "I organized, relocated, and updated relevant tasks migrated from Asana to Jira on the Social Media and Marketing projects into appropriate categories and corrected assignees, ensuring that copywriting tasks would not be misplaced. Relevant information was
also documented on the Investor Social Media Confluence page," added Suule.
To manage other marketing activities, we created a separate project in Jira, which was initially a Jira Software project. Still, after user feedback and further research, we changed it to a Jira Work Management (JWM) project.
The requirement to visualize tickets in the calendar view, a feature unavailable in a Jira Software type project, supported the decision to opt for Jira Work Management. You can read more about Jira Software vs. Jira Work Management in our previous blog post.
Customer experience team
Bondora's customer experience (CX) team collaborates with other teams daily.
"Our team has had the most significant challenge as we are the company's heart and must collaborate daily with other departments, such as marketing, AML, product, legal, and finance. Finding a way to keep track of everything and be on top of things is the hardest part of our job. We have been using different systems with different departments, so it is good to have everything in one system, as then, you can easily link various tasks with other boards and projects, which Jira provides," said Lisette Rohunurm, a customer experience team member.
For example, the customer experience team needs to be able to link a Jira ticket to a product team ticket when registering customer complaints or feedback. With the integration, agents can seamlessly create Jira tickets directly from Zendesk and link Zendesk engagements to a Jira ticket.
"This project urged us to review our processes even more, align them, and note them down. Create better task templates and remove unnecessary fields," Lisette explained the added value of the transition to the new software.
Creating templates for the "Description" field was a common requirement in almost all teams, for which we implemented the Issue Templates Agent.
Finance and accounting team
Bondora's accounting team uses Jira for day-to-day communication and to delegate tasks to other departments in the company, especially customer service.
"Adopting Jira has enhanced our accounting processes and the preparation of expense reports. Jira enables us to swiftly respond and coordinate activities associated with issues related to expenses, invoices, and lost checks," expressed Karin Köösel, a member of the accounting team.
The administration of expense reports was associated with the necessity for the generated reports (tickets) to be uploadable to the accounting program in PDF format.
As Jira doesn't provide default PDF export functionality for tickets, we implemented the Xporter plugin. This plugin facilitates the export of an issue, including predefined templates, and allows the export in PDF format, among other capabilities.
"Also, in the accounting team, we use separate Jira boards for lost checks and invoices. Boards allow us to track and manage missing documents and create tasks for specific individuals as needed," Karin explained the management of accounting processes in Jira.
Automation rules, issue-level security and user experience nuances
There was a need to explicitly restrict permissions in several teams, so we implemented the issue security scheme. Issue security scheme includes security levels, in which the access permission to the ticket is configured based on the Jira group, role or by individual user (we do not recommend using individual users).
Selecting a specific issue security level can be accomplished manually or automatically. As an illustration, we implemented automatic assignment of security levels for equipment ordering within the "Office" project with Jira automation.
There was a requirement that all company employees must have permission to create issue in the Office project. However, viewing issues created by colleagues had to be restricted.
The best solution to this requirement was an automation rule that automatically added a security level to the issue at its creation. To restrict visibility of tickets to the entire team, we configured access to the "Reporter" role and the Office team group within the security level.
Through Automation, we streamlined the process, eliminating the need for the reporter to manually choose the security level when creating an issue.
Managing priority tickets in the board view
We implemented automation rules in various projects for various purposes, but the primary goal was still efficient issue management.
For example, in the Expansion team, we used Automation to solve the requirement that if an issue's "Due date" value is within the next 30 days, the ticket must automatically move from the Backlog status to the To do status. Consequently, the issue transitions from the standalone Backlog view to the Kanban board, the primary interface for issue management.
Also, there was a need to quickly and easily distinguish the priority tickets in the board view.
The requirement specified that issues with a "Due date" value within the next 7 days should be displayed in yellow on the Jira board, while issues with a "Due date" value in the past should appear in red. We implemented the color logic based via board settings with the help on JQL.
Illustration 1. Example of a Kanban board with card colours.
Bulk cloning issue
Several teams also expressed the need to clone issues as there are standard activities that are performed every month (for example, accounting reporting) or quarterly.
Since Jira does not allow bulk cloning of tickets by default, we first tried to solve this requirement with Jira Automation. The solution for bulk cloning was theoretically functional, but since it was also necessary to edit fields of the created issues, the workaround solution would still require additional work in the form of bulk editing issues.
To address this challenge, we opted to implement Deep Clone for Jira. This plugin facilitates rapid and user-friendly bulk cloning of tickets, along with the capability to edit fields during the cloning process.
Implementation of a new software through comprehensive support and training
The migration from one software to another is a gradual process, requiring careful consideration of various technical aspects while keeping the end user in mind.
"The main challenge we encountered was changing the mindset of the teams and the entire company to adapt to Jira's logic," Aleksandr said.
"As with every significant change, training our agents and getting used to the new system takes time. The biggest hurdle was that each team uses Jira differently, so we needed to get used to their board setup, task fields, etc. Initially, this caused a lot of confusion, and we had to take extra time to review created tasks and smooth out the processes. However, it has improved significantly, and we will likely use the full software functionality, like personal tasks, etc, soon," Lisette said.
To get the teams on board and build trust in the new software, we did on-site training for end users in the project's initial phase. During the beginner's training, we learned to use the software through theory and practice and clarified the most important concepts and terms.
During the adaptation to the new software, users frequently have additional questions and thoughts. It is crucial to consider this factor when planning resources to ensure effective and operational support throughout the transition phase. We imparted technical knowledge in Jira administration and shared best practices with Bondora's Jira superusers through administration training.
Future perspective
A profoundly designed project structure lays the groundwork for future advancements in high-level planning. In the realm of Jira, Bondora has currently prioritized the implementation of Advanced Roadmaps, aiming to integrate the management of company initiatives and strategic goals into the same system.
