13 min read
Software production today isn’t the same as 20 years ago. Software has become more and more complex, with distributed teams literally all around the globe, and reliant on people specialized only in a specific part of the process. Also, UI/UX has become a very important issue as the competition for capturing new users and retaining the current ones’ increases.
Over the past year, I’ve worked on a dozen projects and almost all of them used a project management tool (PMT). I am not going to give you a sales pitch for one specific tool today, but rather, I’m going to give you an inside view from a developer’s perspective of how these tools are used in real life as well as an overview of two representative tools. Hopefully, this article will help decision-makers and developers figure out what is most convenient for them, their team, and the project they are working on.
Why Use a Project Management Tool?
When I was starting out, most of my projects didn’t rely on a project management tool, so you might be asking if you really need one. Can’t developers just create software without them? The answer is that it depends on multiple factors, so let’s analyze some of them.
The Rise of Global Teams
On most projects, I find myself working for people around the globe, and while that’s really awesome, it also poses a range of challenges that an office team won’t be facing. Time zones become a real issue when you are trying to get a colleague to fix or modify some part of the system in which you’re not sufficiently proficient.
There are also scenarios in which you might not be able to talk to the other developer more than once or twice per week. Project management tools help make such collaborative processes easier because they become an official (and, for practical reasons, sometimes the only) channel for team members to communicate their needs back and forth.
Of course, it is not merely about communication between individual members of a distributed team. PMTs also provide more information and visibility to all team members, allowing them to track the progress of other team members and plan their activities accordingly.
You may be thinking you can get the same results simply by collaborating via email or other communication channels. A client of mine did that on a project I worked on a few months ago, and it was a nightmare. People used multiple emails for communicating, so it was hard to keep track of different threads. Also, communication about a single issue becomes a puzzle broken into different pieces living in different email conversations. Most email conversations touched multiple issues which made it harder and harder to keep track of what was left to be done.
Project management tools solve this by having one stream of conversation dedicated to each issue, making your life easier, as they allow you to find everything you need (designs, APIs, and feedback) in a single click. From a collaborative perspective, this can make a huge difference, as project management tools enable everyone to access and view all segments and stages of the project, reducing the need for constant communication and updates.
Manage Project Requirements
One of the biggest issues facing teams that don’t use a project management tool is caused by the intrinsic nature of software. Maybe you’re working at a startup and you have pivoted more than a couple of times. Maybe your goals and requirements keep evolving as you work on the project.
In this context, we should think of software as a living being. Regardless of how well the initial plan was drafted, there is always a good chance it will need to change. However, sometimes these changes are not being communicated to all team members. Executives can have a conversation about a new feature that will give you an advantage over your competitors, but if the manager does not express this to the rest of the team, it won’t happen.
If it wasn’t written down, it might even be forgotten by the manager and CEO, too. Not having a place where you have the latest and the official requirements will cause you to lose a lot of time and money. PMTs offer a single point of truth, a single place where all requirements and information are stored for the duration of the project. This is not only about features not being added that you can add later—I’ve developed entire features just to discover that I wasn’t told we are no longer supporting that feature.
Memory and Time Efficiency
“The palest ink is more reliable than the most powerful memory.”
We can only handle so much in our head at a time. When you have a call with your managers, and they bring up a dozen different issues during the conversation, at some point, something is going to be lost. You could try to write down the most important points yourself, but still, something could fall through the cracks.
Having requirements written down instead of talking about them on a call is a good way to catch potential missing elements in the flow or to detect things that might block you from implementing that issue at the moment. Software development is not linear, so you might start working on a feature today but have something more urgent to work on in the product and come back a couple of weeks or months later only to realize you’d forgotten what exactly was required.
That’s why having requirements written down can save you time, either by not having to remember or by avoiding having to discuss the same feature over again. Time efficiency is very important as the software is more complex, so you might take advantage of just having things written down, to cut your meeting time in half or more, by focusing only on the issues that you need to clarify.
This is related to the previous issue of keeping track of communication related to the issue that’s being addressed and just keeping track of features of future requirements without you needing to talk about those things.
This helps the developer both to maintain focus on creating things that are required at the moment and learn what’s coming next. It’s not just about convenience and easy access to information. The added level of visibility allows each team member to see the big picture and plan ahead accordingly.
Key PMT Features
So, what we are looking for in a PMT is a tool that helps manage the conversation by keeping discussion of different issue separate and well organized. That helps communication between people in different time zones and different teams while at the same time serves as a repository of the official vision of the software, helping you keep focus and saving you time by reducing friction in the development process for the developer, project manager, and everyone involved in today’s software development landscape.
Jira is a very powerful PMT that was specifically designed for software development. However, not everyone knows all the features of Jira and it can be overwhelming if you’re a business owner trying to manage your first project. If you’re reading this as a person deciding between different options but haven’t used Jira before, I recommend watching some tutorials first so you can truly take advantage of its power.
There are three words with which I can define most of my experience with Jira, and one of them is sprint. A sprint is a time period in which the team works toward completing certain goals which can be closely related or not. It’s completely flexible. Jira sprints typically last a week, which, in my opinion, is the optimal duration.
From a developer’s perspective, this gives you the flexibility to have multiple things assigned to you and work in the order which is most comfortable for you, which can be working on a hard one and then an easy one to relax, or maybe work on 2-3 that are closely related at the same time. This empowers developers to make some decisions while keeping focus at the same time on delivering in time.
Jira Epics and Issues
While sprints group tasks in the temporal realm, epics can group tasks by subject. For example, you can divide your tasks into sprints per week, but you can also group the tasks at the same time in front-end and back-end. When dividing tasks by subject, you can assign a developer to a subject.
For example, you can have an epic for migrating data from an existing database, so you might call that epic DB Migration, and since all the tasks in that epic are related, a single developer can be the one in charge of that during all the sprints. This avoids having two developers spend time learning the old database, making development more efficient.
Issues, on the other hand, are the things that need to be done, which can belong to an epic and a sprint. There are multiple types of issues and those are story, task, and bug. A story has the peculiarity of having subtasks, which can be used to break down an issue into smaller pieces that form a complete picture when taken together—this avoids creating a large number of tasks, instead focusing on a single item to be completed.
Tasks in Jira are issues that are very specific and don’t have subtasks. When something that needs to be done is very straightforward and there is no point in trying to break it down, it’s a task. Bugs are things to be fixed—keeping bugs as a special category will help you understand how much are you fixing as opposed to how much you are progressing in the project.
Communication is a big part of the equation when working on a global team that works across multiple time zones. Working “around the globe” is not a metaphor, but a reality many developers live in. One of the things that’s difficult to communicate from managers to developers is the priority level of a task. Imagine the following scenario using a todo list:
The developer sees that during this week, they have seven tasks to complete. Some of them are hard and some are easy. One critical task for the manager, however, is very complex, but to the developer in a todo list, all tasks are equal—they might choose to go for the easier ones first, leaving the critical one for the end. If something unexpected happens and the list doesn’t get finished, it’s the most important task that gets cut, or it gets finished in a rush (probably sacrificing quality in the process). This is very easily solved in Jira by having priorities, which lets developers understand what is more important or critical to be completed.
Content, Content, Content
One of the things you will really appreciate about Jira is the amount of content you can place under each issue; you can add images or links as well as tag other team members—while this is all true about Trello too, the UI really entices you to place more content, which helps have more data on each task.
The Pros and Cons of Jira
Jira is a very well-established tool with a lot of features that were incorporated specifically for software development. It offers a bunch of integrations with other systems and helps you keep well organized. It is especially good for (very) big teams.
Jira, being a capable, feature-packed PMT can be somewhat daunting for a novice developer. The experience can be overwhelming—sprints, epics, and issues can all blend together. This is especially true if the manager is a client with little experience in software development, trying to manage a team of developers. I highly recommend Jira for big teams and big projects that will take a while to develop (more than a couple of months), as well as for experienced managers (clients) and developers.
- Designed specifically for software development
- Allows each issue can have a lot of content, like links, images, attachments
- Has a mobile app with notifications, which helps you keep track of your issues all the time
- Integrates sprints with the core of the product
- Provides very intuitive task filtering so you can focus on the tasks that are relevant to you
- Has many features, so you can easily underuse the software
- Requires some training to take advantage of all its features
- Requires (or at least is helped immensely by) an understanding of Agile development
- Can be an overkill for a small project with a small team
Trello can be summarized in a simple phrase: “boards with cards,” a.k.a. Kanban. At first sight, it might even way too simple to an untrained eye; however, simple things can be extremely useful.
Simplicity is a powerful concept. That’s part of the reason why iPhone and Mac became so popular, as their OS was simple and joyful to use. While Jira feels like having every single thing you can think of, Trello feels like having just enough to get you through. No epics, no stories, no sprints—you simply work on a card and move it through the different stages (columns).
Keeping in mind that all of these exist in Jira as well, I’ll explain a few of the features that shine the most in Trello.
Trello makes defining stages very easy—simply create a column and start using it. The most common ones are To Do, Doing, Review, and Done. Because of its simplicity, you can add other columns like On Hold (Jira can do this too, but it feels like they are lost unless you go explicitly looking for these issues) or create columns for different parts of the system like Todo Front-end or Todo Back-end. This is excellent when the team and project are small, like a simple website, a widget, or an extension, where there aren’t many members or tasks to manage simultaneously.
You can assign a card to members and that’s how you assign a card to a developer—very simple there. You can tag other members in the comments as well, which helps everyone involved in an issue to keep communicating about it.
With a single click, users can easily filter their cards or cards belonging to other team members, which is especially handy in Calendar view.
Due to its simplicity, Trello has the Kanban visible whenever you’re opening the contents of a card. It’s a very visual approach, as you can’t escape this view. Also, cards can have images which are visible on the board.
This is something that Jira does not have (or at least I haven’t seen it being used on a real project). Since a picture can say more than words, you can easily see what’s going on without opening each ticket.
In addition, Trello’s colorful tags can be used to add even more information without having to expand a card. With a bit of good organization, these Kanban equivalents of Post-It labels can prove very helpful and spare you a lot of unnecessary clicking.
Due to its inherent simplicity, Trello pushes you to keep things simple and to the point, avoiding the feeling of being overwhelmed by mountains of information. Many times, you will be working on a project in which you’re being constantly bombarded by notifications for items you’re not even involved with.
This extra noise seems to be somewhat reduced on Trello, at least in my experience. Since Trello isn’t so user-friendly for adding information, I found out that issues tend to be smaller, meaning that tasks are broken down into smaller pieces than in Jira. With some planning, these small tasks should not generate too much noise.
The concept of gamification is, in part, to take a simple task and turn it into a game through the use of rewards. “Difficulty doesn’t put you off if it’s supplemented with rewards,” as pointed out in this article on the Trello Blog.
There is a boost of adrenaline (or dopamine) whenever a ticket is being moved from one stage to another. Since you can’t move a card to a different stage without dragging it on Trello (whereas on Jira, it’s easiest to just change the status of an issue), you get a physical connection with the progress you’re making. At some moment without you realizing it, you feel like competing against yourself to knock out more issues on that day than the day before (I hope I’m not alone here with this feeling) or you just feel like battling to make the todo column empty as quickly as possible. Many software products use gamification today to create a bigger engagement like the views and likes on most of the social platforms—that mechanism of action-reward is what keeps people engaged in the platforms.
The Good and the Bad
I’m still amazed by how using Trello feels joyful, and certainly, its simplicity is crucial to this experience. Tasks tend to be smaller—although you get the same job done, it feels better to move three tasks to the “For Review” column than it does to change the status of a single Jira story to Done. (I feel the conversion rate of one Jira story is about three cards on Trello.)
This is ideal for new developers or business owners trying to manage a project because the barrier of entry is very low. Trello is easily mastered by anybody, software engineer or otherwise. The problem is that Trello may be too lightweight for certain projects and huge teams. Although you can easily create additional boards, having a lot of developers working on a single board can spell trouble. It’s just not the same, qualitatively, as Jira’s shared workspace.
- Low barrier of entry—you don’t need any experience
- Simple UI
- Extremely visual—you get the idea immediately
- Ideal for small projects and small teams
- Not a friendly UI/UX for adding a lot of details to an issue
- Doesn’t translate as well on mobile, as you physically need more space to display a kanban board
- Doesn’t have a way (at least, intuitively) to prioritize tasks
Should I Use a Project Management Tool?
Yes—I think that in today’s typical situation, in which the manager or business owner isn’t available to answer questions 24/7, you should really think about using a tool just as a way to have a repository where everything required is written down in a clear manner. This will help you avoid confusion or missed items because they were forgotten on a Skype conversation or buried below hundreds of emails. If your project is smaller, like a hobby site, a PMT might be overkill.
Which One Should I Use?
The answer to this is the one that best suits your needs. If your team consists of more than four people and the project will last for more than a year, I’d go for Jira. If that’s your case, I highly recommend that you read more about how to use Jira and how to use software development methodologies.
If your team has less than four people and the project is a simple website, or maybe adding some features to an existing project, I recommend Trello due to its simplicity. As always, with tools, both can get the job done, but that doesn’t mean the best one is the same for everybody.
Understanding the Basics
What is a Jira ticket?
A Jira ticket is like an atom is one of the smallest units in managing team. A ticket can be different things in the case of Jira it might be a task, story or bug. Basically is a task you need to complete, that is listed on Jira as a single item.
How does Jira work?
Jira works by facilitating the organization of large teams of developers, letting you track the activities and the current state of each activity. For that purpose, it contains many features like priorities and sprints, and it’s Agile friendly.
What is Jira Epic?
An Epic is a group of stories, tasks that are related by the purpose they are trying to achieve. Imagine you’re doing a social media platform: An epic might be a website which contains all the tasks related to the website, another one can be the app that contains issues related to the app etc.