Transition from Trello and Clockify to Jira

1. Software house project management tools short story.
2. Why we moved from free Trello + Clockify (Which we used for over a year) into paid Jira
3. Jira’s alternatives analysed
4. How to move project management from Trello into Jira
5. Upsides of moving software development management to Jira
6. Downsides of moving from Trello to Jira
7. What developers think about this transition
8. After 1 year of using Jira

Software house project management tools short story.

Our approach to select tools is simple. We always use the solutions adequate to the requirements or needs.

So as a company we started as a 2 freelancers working together for clients. We chose Trello as a main task management tool and Toggl for time reporting. For some time it was working perfectly.

When we needed better matching between the systems, we added a Trello plugin called Card Numbers, which allowed us to generate task codes like TH-666 which ended up in Toggl as a task names. This way we were able to provide some reports for the clients.

When we reach more than 10 developers working with us, we made a decision of moving from Toggl to Clockify – which is basically a free copy of Toggl. So here, the main factor of change was the cost: 11 x $10 = $110 per month for Toggl, vs free Clockify which had exactly the same features at that point. The decision was easy.

The long story short, we spent about another year with this stack.
At the beginning these tools are all you need. If you start a 1 person consulting company with Jira – this is in my opinion a total overkill. Start small and then improve.

Why we moved from free Trello and Clockify (Which we used for over a year) into paid Jira

Everything was working fine, but at some point we started to see lacks of our software.

A client asked us for a detailed report for the project. We’ve been working in a kanban methodology and each week we had a demo, where we presented progress but also gather feedback from the client, write it down and create the tasks. In most cases it was small features or changes, but still – change the initial estimate, which we missed.

Long story short – after a couple of months, we’ve been over the initial estimation, over the budget and not all the tasks from the initial breakdown were implemented.
We thought it’s clear – we’ve been adding tasks to the process, so we couldn’t work on the initial tasks at the same time. And then the nightmare began.

We had initial estimation in the spreadsheet – created before the development started and then all the tasks were added to the Trello. All tasks from the feedback went directly into the project management tool and not into the spreadsheet.
Additionally, the spreadsheet was built for business. Trello must be clear for both developers and the client, so there were additional tasks, sub-tasks (in Trello there is no direct link between the tasks), so we didn’t have one to one correlation between the spreadsheet and what was done by devs.

When the client asked for the report, we had a pretty big problem.

Tasks were in Trello. Time reports were in the Clockify. Nothing matched with the initial spreadsheet. Tell me – which tasks were over the initial estimation, which tasks match the estimated row from the spreadsheet, and which were added after feedback gathering.

Of course, it wasn’t only about the tools, there were also our management and communication mistakes.

I personally spend over 14 hours solving this, building a report in the Excel, based on the data exported from Clockify and trying to match them with the descriptions and comments in Trello.
(At this point I gave myself a Master’s degree of Excel)

This story shows, what was the main factor when we decided – we need better tools.

Other factors were more trivial:

• We needed subtasks – when the requirements get bigger and bigger, we need a good way of grouping the tasks. There is no way of keeping it as a Checklist or other workarounds that we tried. It’s better for both the developers, the client (that see the movement over the board not 1 task in progress for 1 week) and for project management.
• We needed time reporting in the same place as we have the tasks. Manual copy and paste of the task code from Trello worked, but there always was a space for error. In Clockify we had the option to add the tasks, but it’s the manager had to add / archive the tasks  for the developers which was very annoying
• We needed reports – a real one, configurable and easy to achieve when the time comes. And to be visible within the app, without a need to export it into Excel to summarize something.
• We needed backlog – in some projects we work on our own, so only the project manager and developers are creating and moving the tasks. But in the others, the client is actively working with the project management tool, which in most cases means that TO DO list is growing exponentially – we needed some separation of what needs to be done now vs the plan for next half year
• We needed wiki – also at some point we started to write down our processes and good practices. Of course the first were done with Google Docs, and of course no one knows where to find them when there was a need. So we agreed that we also need some kind of wiki to gather it in 1 place.
• Free Trello has a limit of 1 Power-Up (plugin) per board which can add e.g. card number generation – so would already pay for this.
• To estimate tasks we had to use the card name and append something like “EST: 6h”. Which should be a totally separate field of the task, not the title.
• When estimating projects we use Google Sheets and when we start work we are not making a backlog of tasks – we could use a single tool for estimation and later defining (when project starts).
• We didn’t use any dashboards to tracks progress and immediately detect issues which require actions like e.g. some task taking much longer than expected.
• Reasonable price per user – at the moment we had about 20 users (our team + access for clients)
• No need to teach customers how to use it – intuitive kanban board similar to Trello
• Ability to convert estimates into sprints and kanban board – in a perfect world, the client comes to us with clear requirements, we estimate them by creating project backlog in the tool, then we sign the contract and everything is ready to be started. Of course, we are not living in the perfect world, but we assumed that it would be nice to get rid of spreadsheets – this one didn’t work (so far) even with Jira.

Jira’s alternatives analysed

Of course Jira was our first thought, as most developers knows it from the corporate world. But we’ve been moving from the free tools, plus we keep our principle of choosing the simplest tools needed, we’ve been looking for the alternatives.

Here is a summary of what we gathered. Also, the rest of the team had their voice in the final decision and the private research is not included here.

If you want to see it better, here is the link to the summary: Link to the table above as a spreadsheet

How to move project management into Jira

Technically this is not a big issue. First result in Google describes in details how to do it: https://support.atlassian.coma/jira-cloud-administration/docs/import-data-from-trello/

But here comes the more difficult part.

How to convince current clients, that transition to Jira is a good decision?

Our selling points to this were:

• Much better reporting, available also for the client at any point
• Clear view for the estimation and time logged by the developers – this is up to you if you are showing it to the client. We are always trying to be as transparent as possible, so our clients can see everything.
• Much more mature tool and ready for bigger projects – along with all pros and cons of it
• Ability to create subtasks, so the more complex issues can be easily split into smaller pieces

Objections to handle:

• We like the current setup, we don’t want to change
• We will have to learn the new tool

How to convince developers, that transition to Jira is a good decision?

Our selling points were:

• Time logging directly in the task – simple start stop buttons without any additional browser plugins
• Better tasks descriptions
• Ability to create subtasks
• Multiple integrations with Bitbucket
• Tasks transition on branch merge (this also work for merging e.g. development → master, all the tasks from in review can be moved to the in test column automatically)

Objections to handle:

• We like the current setup, already got used to it
• THIS IS SO SLOW – and I’ll get back to this point later, because it is
• Things are much more complicated than in Trello

Upsides of moving software development management to Jira

Let’s talk about the good point of moving to Jira first. Cause there is a lot of them.

1. Customization – Jira is a very big piece of software, allowing you to configure a lot of stuff for your needs. Probably that’s why it’s so popular, because most of the companies are able to make it work the way they need.
2. Automated Log Work – This was a key plugin, that we’ve been looking for. This allows our devs to log time directly into the task, without going somewhere else, using extra Chrome extensions or other application. Everything is in 1 place
3. Estimation and Time spent in 1 place – same as above, we see the actual time spent by the developer in the context of original estimation. With 1 look at the project you see how is it going.
4. Configurable fields – For our company the key fields are the ones connected with estimation and time spent. We can display them in the task details, in the kanban board, in the backlog – this one is simply working as we need
5. Reporting – Thanks to Automated Log work we have access to all the reports we need. They are also configurable and exportable to the Excel if needed.
   The cool thing is, that you can configure your own filter / grouping and simply save the link. The next time you will need to check the same report with different dates you can simply get back to the link and only change stuff you need.
6. Subtasks – this was also one of the key features we need and also just works great
7. Epics – another ability to group tasks, very useful, when we split the project into phases.
8. Roadmaps – this one is tricky. (Please verify this point against documentation, it is written in January 2021) When we started with Jira, we were happy that we will be able to estimate projects with a roadmap feature and when the contract is signed, simply start the development.
   Turns out, that roadmap is available in the NextGen projects and the hour estimations are in Classic projects. So these 2 features couldn’t work together. At the moment there is some beta version available in the Classic projects, so hopefully we will get to this point soon.
9. Integration with Bitbucket – as we are using Bitbucket as a main code repository, we use all the features that Jira provides and this just works great
10. Confluence – this is an Atlassian version of Wiki – we’ve been using it since moving to Jira. Works fine but with our current number of users is getting expensive, so we are moving to some standalone Wiki. This is a feature that doesn’t necessarily have to be in 1 place.
11. Tasks history – each time log, transition between columns, field change results with a log. Which is sometimes very useful, when we have to check who’s done something.

Downsides of moving from Trello to Jira

Jira is not perfect. Probably each person that used it, at some point were irritated. We are the same and here is why.

1. This is SLOW – Trello is an extremely simple and fast tool. When you move to Jira, the difference in speed is enormous. And it’s in every aspect – task creation, moving stuff around the board, switching between the tasks. There isn’t much difference if you have 3 or 300 tasks so test it before you decide to move.
2. Permissions – at the beginning this was a nightmare. In Trello, it’s simple – each board is a separate project, you add who you need to the proper project – done.
   Here we have Users, Groups, Roles, Permission Schemas – to find a proper way of setting up the project and making its available only for particular clients and developers ends up with an article in the Confluence.
   This stuff should be much simpler to configure.
3. Refresh – when managing the tasks and there is more than 1 person on the board to see the changes live, you have to refresh the page, which sometimes is annoying because you don’t always see the latest state.
4. Lack of built-in functions – ‘Automated Log Work’, ‘Checklist’ are plugins that we had to add – no idea why Atlassian is not building it as a core of the system.

What developers think about this transition?

All the opinions and thoughts are by the company founder, I’m somewhere between the developer and manager, doing both type of works. But what our developers (that remember moving from Trello) say about the transition?

1. I really love the feature that allows you to create a branch directly from task. – Bartosz Radlak, Mobile developer
2. 1 complete system is always better than 2 separated – Adam Kortylewicz, FullStack developer
3. I preferred Trello. Board loading time was faster, and it definitely was much easier for the client to manage. – Jan Wielgosiński, FullStack developer
4. I’m disappointed with Jira’s speed. Everything is slow to load. But its capabilities make up for it. We now have bug and time reporting in one place, convenient Bitbucket integration, advanced search, reporting, permissions, and we get more than our knowledge of the tool increases. – Filip Mazur, Mobile developer
5. I think the only major problem with Jira is the speed and maybe that it can get overwhelming for a new user as it has many features and a lot is happening. But once you get used to it, the amount of features and having it all in one place (tasks, sub-tasks, time tracking, branch creation from within a task and reports) is a massive advantage. Although at times slower, I wouldn’t go back. – Dawid Abram, FullStack developer
6. More software dev focused than Trello, has some dedicated fields from the scratch like estimates, components etc
   Integration with code repositories, build tools
   Might not be the fastest thing out there, but speed is not a huge concern for me
   Pricing model – with the way we work, we need to pay for every single client user, it would be nice if they could offer free “guest” accounts
   Access management – it is very feature rich, but complicated as well, setting visibility of projects for users is too complex – Wojciech Soczyński, CEO, FullStack developer

After 1 year of using Jira

All in all, I think that we’ve made a good decision. I don’t know if this is a perfect solution (for us) or not, but we were able to adapt it for our needs.

The list of pros looks much bigger than cons, which makes me happy.

The developers are not a big fans of this solution, especially the ones that worked with us on Trello.

The cost is not huge for Jira itself. As I mentioned, we are switching Confluence to a standalone Wiki, because we don’t see any extra value of having it in 1 place.

Big thanks to Filip Mazur, for creating the decision log in the Confluence, which reminded me some points what was the process of choosing – very good practice.