Notion vs Jira | Why we decided to switch to Jira as ticketing tool
This is the pragmatic comparison of tools my team used extensively.
We are a distributed team, in a startup company, working on software development for in-house products. Our team consists of product managers, product designers, software developers, QA, SysOps, etc.
We used Notion for four months and switched to Jira. Below is the explanation why.
Let's start with Notion.
When the team got invited to Notion, it looked like a "known tool". Soon, it was obvious that the rest of the team had no clue how Notion works.
Whole Notion works around three to four top-level containers:
Database
Page
Subpage
Template
Database - You can imagine the database as a spreadsheet. You add columns and define its labels and data types (called properties in Notion)
Page - One database can have many pages. Actually, every entry into the database is a page. Page can exist outside of the database as well.
Subpage - Subpage cannot exist without a page. It's a classic parent-child relationship.
Template - Well, it is a page template, and it links to a database.
Upsides
Flexibility.
You can define databases and shape them for every need. Todo list. Project tickets. Countless existing templates to reuse and save time.
Easy to organize documentation with a powerful text editor.
Filtering.
An advanced feature. You can create a "view" on top of the database and set up a filter for that view only, without affecting anything else.
Custom templates.
Countless, very useful and nice-looking page templates are available. What's more, you can define your own, and save time when creating "tickets" (read: pages).
Downsides
Filtering
Although listed as an upside, this is where Notion is a bit harder to understand. What was the challenge?
You can create views on the database, and apply the filter on a view.
Editing a view filter and other setups don't affect the database.
Editing the page inside the database will apply the change across all views.
Setting up the filter on a database will affect everything.
Our team struggled to differentiate view from a database.
In our setup, we had a personal page for everyone called "My tasks". That was a view on top of the database, filtering by assignee property.
And that worked. However, we needed some custom filterings all the time. Due to difficult understanding, most of the team members used filtering options on the database level instead.
By applying the filtering option on a database, you'd affect the whole system. Every view, and how the database looks like for everyone else would change all the time.
We had this issue at least three times a week. As time passed by, it become a joking topic in the team, followed by a rant.
As a Director of Engineering, I have started asking myself. How many times we lose focus, started ranting instead of working. Why isn't this tool serving its purpose? Are we using it in the wrong way?
Permissions
Very high-level permissions are available.
The product will evolve for sure. But not being able to set permission on "who can change database schema" is a huge problem.
Why? Someone clicked on a database and accidentally (or not) added a new property. This property shows up on every view, for everyone.
We could argue that "it's great how flexible it is"? Well, NO. As a product manager or project manager, we have no control over how to manage tasks, nor processes if everyone is intervening.
What's worse, you can delete the property as well. This is where things started to go south.
Isn't there a better way to start your Monday than to face a Notion database with the "Project" property removed?
We noticed this after 2-3 hours of work. Every filter everywhere is affected. Thousands of tickets mixed. There is no non-destructive way to revert the change.
A team member that made the change, reverted the version of the whole database out of panic, effectively canceling 3hrs of work for the team of 40.
There is an option to lock the database though, but it's not efficient, as you have to unlock it and lock it many times a day.
There was no permission to set to at least prevent:
database property removal
database restoration process
Workflow
As with any other ticketing system, you'd have a ticket status. In the case of Notion, it's a property "Status". A single-select data type, with values such as "Backlog", "To do", "In progress" etc.
Our views were set around the "Status" property, so we have had a board of tickets with these columns. What proved to be a problem for our team is the actual flexibility on where you can move the ticket.
In Notion, you can move it anywhere. I have spent so much time explaining the ticket flow.
From "In progress" ticket has to go to "QA".
Then from "QA" to "Done".
From "Done" it would end up in "Deployed" and "Closed".
Closed means, it's in production and tested/verified.
So often, developers would move the ticket from "In progress" to "Done", or even worse to "Closed". This was causing so much confusion, untested tickets, communication overhead over a single ticket.
Notion conclusion
Fantastic flexibility came with a price for us. I was spending 10-20% of my daytime communicating with team members how to use Notion.
Fixing filters, views, adjusting permissions, etc.
I even organized a "Coding Friday" with a topic: "How to use Notion". All with examples and differences between database, view, page, and template.
Without special positive outcomes.
Team frustration caused some team members to start using Github issues in parallel. Then they would sync (manually) Notion to be in the same state as Github.
This was a deal-breaker already. Imagine how inefficient this was. The tool should help us, and this wasn't happening.
It is a great tool for documentation. Its text editor is state of the art. Organizing pages, subpages, embedding external content is fantastic. Public exposure of single pages is so useful. When you have to present something to team members without a Notion account, it's a click away.
Pricing is questionable. Besides the tech team, other team members started applying, and quickly we had 100 accounts. Cheaper subscription packages on Notion have limitations.
One that I disliked is the number of "timeline views" (read Gantt charts) you can create. Come on. I'm trying to create a view, trying to organize myself and you're limiting the number of views ??
All in all, it was a cost of $10k a year for a tool that wasn't too efficient for us.
Jira
We needed a ticket management tool. By running a quick poll on Slack, Jira turns out to be a tool everyone worked with before.
I've exported all pages from Notion into CSV. Through Jira importer mapped the Notion properties to Jira fields and run the import. In a matter of hours, I had a setup in Jira which we used for tracking the progress of development.
Upsides
Workflow
By setting up the workflow of the tickets, all that communication overhead such as "where this ticket should go", disappeared.
The tool is serving its purpose. It is helping the team to do their work, without thinking of "how to use ticket management system".
Automation
Jira automation is making things even simpler and no one needs to think of "to whom from the QA team to assign the ticket".
Jira will do it, because someone already thought about it and set it up.
Github
Integration with Github makes it so easy to navigate back and forth. Impossible with Notion.
Team satisfaction
To an engineering manager, it's relieving to see the team happy. This change motivated the team, as they no longer have to struggle with simple tools.
Price
We are using Standard subscription. Together with the Confluence subscription, it still costs us less than Notion subscription on an annual basis. Worst case, it'll cost the same.
Downsides
Complexity
Jira is rather complex to set up. All the issues, types, projects, permissions, screens, schemes, fields, and whatnot. It is a time consuming to set it up.
I was relying on default setup for new projects, while I was setting up reusable setup in the background.
Once the reusable setup was ready it was a matter of few clicks to connect it with all projects.
Less flexible
Well, this week I googled "How to support product backlog and sprint backlog in the same project in Jira". It turns out it's a hard thing to achieve.
In Notion, it would be a matter of adding a "label property" and filtering with it.
Expensive additions
It's the same with all other products. As Notion puts limitations around subscription levels, similarly to use some advanced plugin with Jira (like BigPicture) might double the cost of a ticketing system.
Conclusion
Notion offers flexibility and powerful documentation options. It is not a ticketing system.
Jira + Confluence = ticketing + documentation, system.
Confluence also offers plenty of templates and a powerful editor. It lacks public exposure of pages as a downside.
The decision point was the efficiency of the team. Jira helped and we're happy with it.